/*------------------------------------------------------------------------------ test-11180-g-teardown-mouse-decoy.p (mouse/keyboard path) ONE-VARIABLE VARIANT of test-11180-g-teardown-mouse.p. Identical topology - secondary WINDOW W2 holds frmO + fO, focus is parked in fO, fO's frame LEAVE DELETEs W2 with NO APPLY, and the transfer is driven by a physical CLICK on fT in the default window - EXCEPT that frmT now contains a DECOY enabled fill-in (fDecoy) placed AHEAD of fT, both in the frame definition and on screen. WHY THE DECOY EXISTS (root cause measured with jdb against FWD 16725 on 2026-08-17, client PID 47876): The parent probe's missing frmT/fT ENTRY is NOT a FocusManager defect - FocusManager.handleFocusChange is never called at all on that path. The actual chain, taken from a live breakpoint stack, is: WindowManager.processWindowEvent:2320 sendLeave(frmO, null) ThinClient.sendLeave posts the LEAVE event ThinClient.invokeTriggers -> RPC the 4GL oLeave runs on the server ThinClient.removeWindow:11927 <- DELETE WIDGET hWin2 calls back WindowManager.removeWindow -> remove -> WindowGuiImpl.destroy:1417 WindowManager.setFocusWindow:1179 -> :1206 window.requestFocus() ... -> AbstractContainer.setFocusInt(fT) WindowGuiImpl.destroy ends with setFocusWindow(getActiveWindow()), whose one-arg overload passes focusFirstWidget = TRUE (verified live), so :1206 calls window.requestFocus() and the focus is driven down to the FIRST FOCUSABLE WIDGET of the newly active window. requestFocus is a raw assignment: it emits NO frame ENTRY and NO widget ENTRY. In the parent probe the default window's first focusable widget IS fT - the very widget being clicked. So by the time the mouse PRESSED is processed, oldFocus == newFocus == fT, the guard at ThinClient.java:22677 fails on "newFocus != oldFocus", handleFocusChange is skipped, and the click's ENTRYs are never dispatched. FWD gets the right answer for the wrong reason only when the teardown fallback happens to land somewhere else. THE VARIABLE THIS PROBE CHANGES: make the first focusable widget NOT be the click target. The teardown fallback should then land on fDecoy, leaving oldFocus = fDecoy != newFocus = fT at the press, so handleFocusChange DOES run and the click is honoured. HOW TO READ THE FWD LOG (the discrimination this probe exists for): * fDecoy LEAVE then fT ENTRY, and NO fDecoy ENTRY -> mechanism CONFIRMED. The fallback landed on fDecoy silently (no ENTRY, exactly as the debugger showed the raw requestFocus does), and the click then drove a real focus change. Note frmT ENTRY is NOT expected here: fDecoy and fT share frmT, so oldFrame == newFrame and handleFocusChange skips both frame-level branches. * nothing after "frmO LEAVE (end...)", exactly like the parent probe -> mechanism REFUTED. The fallback did not land on fDecoy, so "first focusable widget of the newly active window" is the wrong description of what requestFocus resolves to. * fDecoy ENTRY appears -> the teardown fallback is NOT silent after all, which contradicts the breakpoint evidence and would need re-measuring. NATIVE OPENEDGE BASELINE - MEASURED 2026-08-17 (verbatim): === test-11180-g-teardown-mouse-decoy start === 01 --- APPLY ENTRY to fO (park focus in secondary window W2) --- 02 --- now CLICK fT - the SECOND field - in the default window --- 03 frmT ENTRY 04 fDecoy ENTRY 05 frmO LEAVE (begin - delete secondary WINDOW W2, NO APPLY) 06 frmO LEAVE (end - no APPLY performed) 07 fDecoy LEAVE 08 fT ENTRY 09 --- F5: settled FOCUS is now: FILL-IN/fT (2nd run; F5 pressed) Reproduced twice on 2026-08-17; lines 01-08 identical both times. Line 09 appears only when F5 is pressed after the click and before closing. SETTLED FOCUS AGREES ACROSS ENGINES: OE reports FILL-IN/fT, and the FWD trace reports settledFocus=fT. So this is a TRIGGER-VISIBILITY divergence (two events never emitted), NOT a focus-state divergence - application code that only reads FOCUS sees the same thing on both engines. F5 ALSO ACTS AS A CONTROL: it produces no ENTRY/LEAVE of its own, only its own log line. That matters for the PARENT probe, whose trailing fT ENTRY was once attributed to the ESC keypress that closes the window. Line 08 here arrives BEFORE the F5 line, so on this shape the trailing ENTRY is click-driven; the parent's line 07 is the same step, which on its single-field frame shows up as a second fT ENTRY with no matching LEAVE (focus never left fT). Do not re-attribute it to ESC. THIS FALSIFIED THE HYPOTHESIS THIS PROBE WAS WRITTEN WITH. The guess was that OE would ignore fDecoy and enter the clicked widget directly, as the parent probe's log appears to show. It does not. OE enters the target FRAME at its FIRST ENABLED FIELD (03, 04), runs the source frame's LEAVE (05, 06), and only then moves WITHIN the frame to the widget actually clicked (07, 08). The parent probe cannot show this: frmT has exactly one field there, so "first field" and "clicked field" are the same widget and the two steps collapse onto it. Consequence for the FWD reading: the teardown fallback landing on the first focusable widget is NOT a wrong destination - OE goes there too. The defect is that WindowGuiImpl.destroy -> requestFocus performs that step SILENTLY, losing OE's lines 03 and 04, while the second move (07, 08) does go through handleFocusChange and should be emitted correctly. In the single-field parent probe the silent step IS the whole transfer, which is why every event disappeared there. FWD 16725 RESULT - MEASURED 2026-08-17 (verbatim): === test-11180-g-teardown-mouse-decoy start === 01 --- APPLY ENTRY to fO (park focus in secondary window W2) --- 02 --- now CLICK fT - the SECOND field - in the default window --- 03 frmO LEAVE (begin - delete secondary WINDOW W2, NO APPLY) 04 frmO LEAVE (end - no APPLY performed) 05 fDecoy LEAVE 06 fT ENTRY 07 --- F9: settled FOCUS is now: FILL-IN/fT Line 07 is the F9 settled-focus probe (F5 is unusable here - it reloads the browser page; see the trigger comment below). It confirms 4GL-side, not just from the Java trace, that FWD ends on the SAME widget as OE. TRUNK CONTROL - MEASURED 2026-08-17: an FWD *trunk* web client produces this log byte-identically (verified with cmp: deploy/client/... vs docs/11180b/logs/...). Two consequences: * the divergence is PRE-EXISTING IN TRUNK, not a regression introduced by the #11180 work, so it can be filed and scheduled independently; * the temporary [11180m] instrumentation carried by the 11180b build is side-effect free - the uninstrumented trunk jar behaves the same. The parent probe already showed the same trunk parity (docs/p2j/logs/ and docs/11180c/logs/ test-11180-g-mouse.log). WATCH THE DIRECTORY WHEN COMPARING LOGS: under docs/11180b/, the "4gl/" subdirectory holds the NATIVE OPENEDGE baseline (9 numbered lines here) while "logs/" holds the FWD run (7 numbered lines). Both paths are branch-scoped by name, so a 9-vs-7 line difference between them is the OE-vs-FWD divergence - NOT a trunk-vs-branch difference. MECHANISM CONFIRMED - this is the "fDecoy LEAVE then fT ENTRY, and NO fDecoy ENTRY" row of the table above. FWD is missing EXACTLY OE's lines 03 and 04 (frmT ENTRY + fDecoy ENTRY) and matches OE's 05-08 in order. Client trace (tag [11180m]) shows the whole chain: the teardown fallback set globalFocus = fDecoy silently; the ACTIVATE arm sent only the window ENTRY; the mouse PRESSED then saw old=fDecoy != new=fT so handleFocusChange DID run, emitted the widget LEAVE, correctly SKIPPED the frame ENTRY (oldFrame == newFrame) and emitted fT's ENTRY. Why the parent probe loses THREE events and this one only TWO: same cause. There the silent fallback lands on fT itself, so the press sees old == new, handleFocusChange is skipped, and the within-frame move that produces OE's line 07 never happens either. Note the ORDERING difference this probe exposes, which no minimal fix closes: OE enters the target frame at click time, BEFORE the source frame's LEAVE runs. FWD re-homes focus only as a side effect of the window destroy, which happens INSIDE that LEAVE. So setFocusWindow(..., false) at WindowGuiImpl.java:1417 would make the events exist but in the wrong order, and would skip the first-field step entirely. NB the "<==" annotations on the log lines below were written FWD-first, from the pre-measurement hypothesis. On OE, line 04 "fDecoy ENTRY ... (fallback NOT silent)" is NORMAL frame-entry behaviour, not an anomaly - read it as "OE announces the first-field entry". The strings are deliberately left unchanged so this baseline stays byte-comparable with future runs. Steps to drive (GUI - NOT head-less, needs a real GUI driver): 1. Focus starts in fO (secondary window W2). 2. On FWD, drag WINDOW-2 aside first (it opens IN FRONT of the default window and occludes frmT; on OE it opens behind and no drag is needed). See auto/gmouse_drive.cjs. NB the click coordinate is NOT the parent probe's [40,137] - frmT now has two rows and fT sits one row LOWER. Take the b_dragged screenshot and read the target off it. 3. CLICK fT - the SECOND field. Do NOT click fDecoy. 4. Log the settled focus (the parent probe could never capture it: ESC aborts the procedure before the post-WAIT-FOR statements run, so the trailing "done" line never appears). Press the key AFTER the click and BEFORE closing. * on FWD (web client): press F9. DO NOT press F5 - the browser reloads the page; FWD only suppresses the browser default for TAB and F3. * on OE: either works. The banked line 09 below was taken with F5. 5. Close the window to end. Log to test-11180-g-mouse-decoy.log. ------------------------------------------------------------------------------*/ DEFINE VARIABLE seq AS INTEGER NO-UNDO. DEFINE VARIABLE hWin2 AS HANDLE NO-UNDO. DEFINE VARIABLE hFrmO AS HANDLE NO-UNDO. DEFINE VARIABLE hFO AS HANDLE NO-UNDO. DEFINE VARIABLE fDecoy AS CHARACTER NO-UNDO FORMAT "x(8)" INITIAL "ddd". DEFINE VARIABLE fT AS CHARACTER NO-UNDO FORMAT "x(8)" INITIAL "ttt". /* fDecoy is FIRST in the frame definition AND first on screen, so it is the first focusable widget of the default window - the slot the teardown fallback resolves to. */ DEFINE FRAME frmT fDecoy AT ROW 1 COLUMN 2 fT AT ROW 2 COLUMN 2 WITH TITLE "FRAME-T (decoy first, click target second)" AT ROW 3 COLUMN 2 SIZE 44 BY 6 SIDE-LABELS. PROCEDURE logit: DEFINE INPUT PARAMETER m AS CHARACTER NO-UNDO. seq = seq + 1. OUTPUT TO "test-11180-g-mouse-decoy.log" APPEND. PUT UNFORMATTED STRING(seq, "99") " " m SKIP. OUTPUT CLOSE. END PROCEDURE. /* NB FOCUS:NAME is the UNKNOWN value for a dynamic widget that was never given a NAME, and "..." + ? is unknown in 4GL, so the whole line would vanish. */ PROCEDURE logFocus: DEFINE INPUT PARAMETER m AS CHARACTER NO-UNDO. RUN logit(m + (IF VALID-HANDLE(FOCUS) THEN STRING(FOCUS:TYPE) + "/" + (IF FOCUS:NAME = ? THEN "" ELSE FOCUS:NAME) ELSE "")). END PROCEDURE. /* fO's frame LEAVE (driven by the click): tear down window W2, NO APPLY */ PROCEDURE oLeave: RUN logit("frmO LEAVE (begin - delete secondary WINDOW W2, NO APPLY)"). IF VALID-HANDLE(hWin2) THEN DELETE WIDGET hWin2. RUN logit("frmO LEAVE (end - no APPLY performed)"). END PROCEDURE. ON ENTRY OF FRAME frmT RUN logit("frmT ENTRY <== target FRAME ENTRY (not expected on FWD: same frame)"). ON LEAVE OF FRAME frmT RUN logit("frmT LEAVE"). /* The decoy: ENTRY here would mean the teardown fallback is NOT silent. LEAVE here is the signature that the fallback DID land on it and the click then drove a real focus change. */ ON ENTRY OF fDecoy IN FRAME frmT RUN logit("fDecoy ENTRY <== fallback NOT silent (contradicts jdb evidence)"). ON LEAVE OF fDecoy IN FRAME frmT RUN logit("fDecoy LEAVE <== fallback landed here, click drove a real change"). ON ENTRY OF fT IN FRAME frmT RUN logit("fT ENTRY <== clicked target ENTRY (dropped by the parent probe)"). ON LEAVE OF fT IN FRAME frmT RUN logit("fT LEAVE"). /* Settled-focus probe: press the key AFTER the click and BEFORE closing. Adds no event to the measured click window (verified on OE: the keypress emits only its own log line, no ENTRY/LEAVE). TWO keys are bound on purpose: F5 - what the banked OE baseline (line 09) was recorded with. UNUSABLE on the FWD web client: p2j.keyboard.js forwards F5 to the server but its permittedKeyStrokes() only suppresses the browser default for TAB and F3, so Chrome reloads the page instead. F9 - use this one on FWD. No Chrome shortcut, and 4GL reserves a default function only for F1 (HELP) and F2 (GO) - see Keyboard.java:1704 - so F3-F12 reach the application untouched. Each logs its own key name, so a log line is unambiguous about which was pressed and the F5 baseline text stays byte-identical. */ ON "F5":U ANYWHERE RUN logFocus("--- F5: settled FOCUS is now: "). ON "F9":U ANYWHERE RUN logFocus("--- F9: settled FOCUS is now: "). /* ---- main ---- */ OUTPUT TO "test-11180-g-mouse-decoy.log". PUT UNFORMATTED "=== test-11180-g-teardown-mouse-decoy start ===" SKIP. OUTPUT CLOSE. ENABLE fDecoy fT WITH FRAME frmT. VIEW FRAME frmT. CREATE WINDOW hWin2 ASSIGN TITLE = "WINDOW-2 (torn down in its own LEAVE)" WIDTH = 40 HEIGHT = 6 VISIBLE = FALSE. CREATE FRAME hFrmO ASSIGN TITLE = "FRAME-O (source, in window 2)" PARENT = hWin2 ROW = 2 COLUMN = 2 WIDTH = 34 HEIGHT = 4 BOX = TRUE VISIBLE = FALSE. CREATE FILL-IN hFO ASSIGN FRAME = hFrmO NAME = "fO" FORMAT = "x(8)" SCREEN-VALUE = "ooo" X = 4 Y = 4 WIDTH = 20 SENSITIVE = TRUE VISIBLE = TRUE. ON "LEAVE":U OF hFrmO PERSISTENT RUN oLeave. hWin2:VISIBLE = TRUE. hFrmO:VISIBLE = TRUE. CURRENT-WINDOW = hWin2. RUN logit("--- APPLY ENTRY to fO (park focus in secondary window W2) ---"). APPLY "ENTRY" TO hFO. RUN logit("--- now CLICK fT - the SECOND field - in the default window ---"). PAUSE 0. /* Keep the session alive so the tester can click fT; the LEAVE fires from the click, not from an APPLY. Close the window to end. */ WAIT-FOR CLOSE OF THIS-PROCEDURE. RUN logFocus("--- done; FOCUS is now: "). RUN logit("--- OE baseline for this shape was UNMEASURED when written ---").