Context
#17844's census at dev a9abb6c1dc lists all three WorkstationNativePopupOverPopupNL arms red, headless, each on its rig check:
the target vessel is fully on-screen
mainScreen: screenX 0, innerWidth 500, availWidth 800
targetScreen: screenX 520, innerWidth 320 → right edge 840 > 800
Bisected on the unmodified spec (headless, --workers=1): 3 passed at e66b6f8142 and at 9a30bc2d74^, 3 failed from 9a30bc2d74 (#19224, Resolves #19220) through dev 08a84ef3be.
The Problem
Rig fact 2 in the spec's docblock says a 500 px main window on an 800×600 display leaves "300px beside it", which "hold a 146px vessel with room to spare". 146 px was never a designed size. It is the macOS minimum width a frameless newborn fell to (resizeTo(0, h)), the bug #19224 fixed. Vessels are now born at their requested 320×240, so a target placed beside the main window ends 40 px off the headless screen. The enlarge arm's 1.5 floor was also calibrated on it ("146 → 280 of a possible 280").
The Architectural Reality
- #19224 is right: a vessel's size comes from its request.
- Chrome will not narrow the main window below ~500 px (rig fact 2), so the room has to come from the vessels.
- The rig already sizes windows through
setBounds (CDP Browser.setWindowBounds). Wide displays take the full-size branch and are unaffected.
The Fix
On the small-stage branch, the one that narrows the main window to 500 px, the rig also sizes both vessels to an explicit width that fits the room beside main and leaves the enlarge arm its headroom (146 px keeps the 1.5 floor's calibration). This happens before the target is placed. Rig fact 2 then states that width as the rig's own geometry, not as a platform minimum.
Acceptance Criteria
Out of Scope
- #19224's sizing (correct).
- A larger headless screen for the whole e2e project: wider blast radius, and it would not replace the rig's own small-display branch.
Related
#17844 (census) · #19220 / #19224 (vessel size from the request) · #18047 / #18400 (the spec and its enlarge arm)
Origin Session ID: 81d1894c-d8fd-4192-8350-42e32eb0101e
Retrieval Hint: "WorkstationNativePopupOverPopupNL target vessel fully on-screen 146px 320px headless 800x600 #19224"
Context
#17844's census at dev
a9abb6c1dclists all threeWorkstationNativePopupOverPopupNLarms red, headless, each on its rig check:Bisected on the unmodified spec (headless,
--workers=1): 3 passed ate66b6f8142and at9a30bc2d74^, 3 failed from9a30bc2d74(#19224, Resolves #19220) through dev08a84ef3be.The Problem
Rig fact 2 in the spec's docblock says a 500 px main window on an 800×600 display leaves "300px beside it", which "hold a 146px vessel with room to spare". 146 px was never a designed size. It is the macOS minimum width a frameless newborn fell to (
resizeTo(0, h)), the bug #19224 fixed. Vessels are now born at their requested 320×240, so a target placed beside the main window ends 40 px off the headless screen. The enlarge arm's1.5floor was also calibrated on it ("146 → 280 of a possible 280").The Architectural Reality
setBounds(CDPBrowser.setWindowBounds). Wide displays take the full-size branch and are unaffected.The Fix
On the small-stage branch, the one that narrows the main window to 500 px, the rig also sizes both vessels to an explicit width that fits the room beside main and leaves the enlarge arm its headroom (146 px keeps the
1.5floor's calibration). This happens before the target is placed. Rig fact 2 then states that width as the rig's own geometry, not as a platform minimum.Acceptance Criteria
--workers=1, runtime root bound: all three arms.Out of Scope
Related
#17844 (census) · #19220 / #19224 (vessel size from the request) · #18047 / #18400 (the spec and its enlarge arm)
Origin Session ID: 81d1894c-d8fd-4192-8350-42e32eb0101e Retrieval Hint: "WorkstationNativePopupOverPopupNL target vessel fully on-screen 146px 320px headless 800x600 #19224"