Repository navigation
refactor(browser): delete browserResize.keyResizeTopLeft; a key resize's page always rides its pane's top-left corner (cmux-ad m6 1b) - #35382
Conversation
…e's page always rides its pane's top-left corner (cmux-ad m6 1b) #35195 landed the interim browser contract for key resizes behind `browserResize.keyResizeTopLeft` (default on). Its OFF/ON film passed (the refactor owner's STATUS 11746: with it on, the page's left and top edges are on the pane edge in every motion frame of px-keys-single-3k and px-keys-held-2). By STATUS 11198 the switch goes once that film passes. No behaviour change with the default on. Removed: - `BrowserResizeTunables.keyResizeTopLeft` (Debug Settings > Browser Resize) and its entry in `BrowserResizeTunables.all`. - `CEFTabContentView.pageHoldTopLeft` and its latch in `holdPage(for:)`. - The off path: a key hold's page on S3's hold edges. `layoutContent` places a held page (a drag's or a key hold's) at the page frame's top-left corner. `pageMotionHold` still marks a key hold (resume after a hide, a drag's end not ending it); its edges no longer place the page. `schemas/defaults/cmux-next.json` is not edited by hand: the base autofix regenerates it. No new test: CEFDeferredTabShowTests.aKeyResizeHoldKeepsThePageOnThePageAreasTopLeft covers the one path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
red: cmux-next checks (god files, concurrency, crash safety, l10n); no finished base run on b1b0f37 to compare; do not merge until green; see lane-rules Default changesThis pull request changes 2 defaults at
Signed off on this commit by Regenerate the snapshot with |
|
Review (codex): SHIP at e389a72 Reviewer: Codex (gpt-6.1-sol), Round 1 verdict, verbatim: |
|
Found 10 test failures on Blacksmith runners: Failures
|
![Fix with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/fix-with-codesmith-light-3x.png)
Summary
cmux-ad m6 1b, the switch deletion. #35195 landed the interim browser contract for key resizes behind
browserResize.keyResizeTopLeft(default on). Its OFF/ON film passed (the refactor owner's STATUS 11746: with the switch on, the page's left and top edges are on the pane edge in every motion frame of px-keys-single-3k and px-keys-held-2; off 50-248 frames off). STATUS 11198 says the switch goes once that film passes. No behaviour change with the default on.Frames: no content kind changes what it shows in any frame (the default-on path is the only path now).
Removed:
BrowserResizeTunables.keyResizeTopLeft(Debug Settings > Browser Resize) and its entry inBrowserResizeTunables.all.CEFTabContentView.pageHoldTopLeftand its latch inholdPage(for:).CEFTabContentView.layoutContentplaces a held page, a drag's or a key hold's, at the page frame's top-left corner.pageMotionHoldstill marks a key hold (its resume after the tab is hidden and shown, and a drag's end not ending it). Its edges no longer place the page.schemas/defaults/cmux-next.jsonis not edited by hand: the base autofix regenerates it.Merge timing: after the first FEAT DOGFOOD BUILD with #35195 is judged by the P0 JOURNEY RUNNER, as for S3's switch (#35161), unless the refactor owner says sooner.
Testing
No new test:
CEFDeferredTabShowTests.aKeyResizeHoldKeepsThePageOnThePageAreasTopLeft(#35195's red-first test) covers the one path.Fleet green at this head: step
8259737de704222f1337b39c(CEFDeferredTabShowTests, BrowserChromePaneMotionParkTests, BrowserChromeSharedEdgeTests, BrowserPaneOneContainerTests, PaneContentPolicyTests, KeyboardResizeContentHoldTests, InternalPageParkingTests): 7 of 7 suites passed.Changelog
none
Proof
No capture: no behaviour change (a switch and its off path deleted).
Observed / Not run
Observed: the fleet step above.
Not run: films (no behaviour change with the default on, which the films already judged).