Repository navigation
[Bug]: Browser annotations sit behind native modal dialogs #16030
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
- Serve this HTML page and open it in the integrated browser:
<button onclick="document.querySelector('dialog').showModal()">Open modal</button>
<dialog><h2>Annotate this heading</h2><button onclick="this.closest('dialog').close()">Close</button></dialog>- Open the modal, activate Annotate, and select its heading.
- Click the annotation comment field and try to type.
Expected behavior
The annotation outline and editor appear above the modal, and the comment field accepts input.
Actual behavior
The editor appears beneath the backdrop and cannot receive focus. Native modal dialogs render in the top layer and make elements outside the dialog inert; the annotation overlay is an ordinary fixed div outside it.
Impact
Minor bug or occasional failure. Comment entry is blocked while a native modal is open.
Version or commit
main @ 7812230
Environment
T3 Code Alpha 0.0.45's collaborative browser on macOS, Electron 44.4.2 / Chromium 152. The actual PickPreload.ts was bundled into a controlled fixture with an Electron IPC test bridge. This reproduced the rendering and input failure; screenshot delivery to the composer was not exercised.
Screenshots, recordings, or supporting files
Activity
juliusmarminge commentedon Oct 5, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for the clear repro and the before screenshot, @GrannoDev! This reproduces from the code on current
main(7812230572f2), the commit you reported, and no duplicate issue turned up. The desktop in-app browser is the only surface that injects this overlay.What I found
startAnnotationinPickPreload.tsbuilds one fixed host and appends it todocument.documentElementatz-index: 2147483646. The outline, label, toolbar, and comment editor all live in that host.<dialog>opened withshowModal()sits in the top layer, above every documentz-index, and makes the rest of the document inert. Because the overlay is outside the dialog, the editor, toolbar, and outline paint under the dialog's::backdrop, andcomment.focus()inupdateStatuscan't move focus onto the inert textarea. Clicks land on the backdrop instead of the editor.windowin the capture phase and hit-testing reaches the dialog contents. The failure is paint order and inertness, not the pick itself.show()dialog doesn't use the top layer, so the existingz-indexstill wins. Framework modals built from ordinary DOM are a separate case.Likely fix area
startAnnotationinapps/desktop/src/preview/PickPreload.ts. One option is moving the overlay host into the active modal's top layer while a<dialog>is modal and putting it back ondocument.documentElementwhen the dialog closes. Reparenting alone wouldn't be enough if the host stays outside the top layer. Open PR #16031 is a patch from the same report.A maintainer will decide on the fix direction.
josecnico commentedon Oct 15, 2026
Also hitting this in daily use on T3 Code (Nightly) 0.0.46-nightly.20261015.3171, macOS, with a real React app (not only the fixture).
Our app opens its modals with
<dialog>.showModal(). With one open, Annotate → Select still outlines the element inside the dialog (thediv.…label shows up), but the comment editor isn't usable, so nothing inside a modal can be annotated. Most of our forms live in modals, so this comes up a lot.Workaround for now: take a preview screenshot and describe the problem in the chat instead.
+1 for the fix direction in #16031.