fix(windows): mount the drag strip ahead of the app root so no-drag opt-outs win - #469
Open
1499501762 wants to merge 1 commit into
Open
1499501762 wants to merge 1 commit into
1499501762 wants to merge 1 commit into
Conversation
…pt-outs win The 36px strip was appended to <body>, after the app root. Electron resolves overlapping app-region rectangles in tree order (drag adds, no-drag subtracts), so the drag rectangle was applied after every no-drag opt-out that came before it -- including this repo's own rule for button/a/input/[role=button]/ [role=tab]/[role=menuitem]/[data-dsh-no-drag]. Controls drawn inside the strip (the conversation header's row 1: breadcrumb, agent-preset chip and every plugin entry registered in conversation.session.header.actions) therefore looked right and never received a click: the point resolved as caption and the renderer never saw a mouse event. Mount the strip as the first child of <body> so the opt-outs that follow it subtract, and keep the marker behind the app content (z-index: -1) so an exempted point reaches the control underneath. The drag rectangle itself is unchanged, so the strip still drags the window wherever nothing opted out. Adds a regression test to test/windows-titlebar.test.ts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The Windows shell's 36px drag strip is appended to
<body>-- after the app root. Electron resolves overlapping-webkit-app-regionrectangles in tree order (everydragrectangle is added, everyno-dragrectangle is subtracted while the tree is walked), so the drag rectangle is applied after everyno-dragopt-out that came before it -- including this repo's own rule forbutton / a / input / [role=button] / [role=tab] / [role=menuitem] / [data-dsh-no-drag].Consequence in the Windows shell: any control that lives inside the strip and comes before the strip in the tree -- i.e. everything the app root renders, including the conversation header's row 1 (breadcrumb, agent-preset chip, and every plugin entry registered in
conversation.session.header.actions) -- looks right and never receives a click. The point resolves as a caption point, the renderer never sees a mouse event, and the window drags instead. The same page in a plain browser (no strip) works, which is why this keeps being reported as "that plugin's button is dead".This file already knows the strip swallows those clicks: its modal workaround hides the region completely "so all buttons (especially near the top 36px) are 100% clickable".
Fix
no-dragrule above is for.z-index: -1), so a point that is exempted reaches the control under it instead of landing on the transparent overlay.Dragging is unaffected: the drag rectangle comes from
-webkit-app-region: drag, not from hit testing. (pointer-events: noneis the other way to keep a marker out of hit testing, but Chromium's region collection underpointer-events: noneis not documented; a negative z-index leaves the region semantics untouched.)Evidence
position: fixed; z-index: 10; height: 36px),document.elementFromPoint(<button center>)returns that overlay, not the button.<body>'s first element child withz-index: -1, andelementFromPointreturns the<button>again.test/windows-titlebar.test.ts. It fails on the current source (mountsAhead=false,behindContent=false) and passes after the change;npx vitest run test/windows-titlebar.test.ts-> 9 passed.Relation to #221
#221 made the shell publish the titlebar geometry (
--dsh-titlebar-safe-inset-top,dsh-desktop-titlebar-inset), which lets a panel keep its content clear of the strip. This is the other half of the same area: the strip's own click path. No published geometry changes here, and the strip still covers the same rectangle.