Repository navigation
fix(app): keep the browser page under a still while a dialog is open - #58958
Conversation
There was a problem hiding this comment.
The change looks good to me. A dialog now goes through the same still-of-the-page path that menus and popovers use, instead of hiding the native view straight away. Hiding when the pane is hidden or the window is in the background is unchanged.
I checked it in the component test harness: browser-pane.spec.ts passes 27/27 with this change, and the new dialog test fails when embeds.tsx is put back to the base version. Type checks pass for packages/app and packages/gui-extensions. I couldn't try it in a real desktop build, so a quick look at the command palette over a loaded page in the desktop app would still be worth doing.
Public API: unchanged (the app's internal embed logic and a test fixture only).
No blocking concerns. One trade-off: like popovers, a dialog now leaves the native page on top for the few frames until its still is captured and shown, where it used to be hidden straight away.
Opening the command palette (or any dialog) made the built-in browser blink: the page disappeared the moment the dialog opened, the pane showed an empty box under the scrim, and it blinked white again on close before the page repainted.
The host embeds hid the native view outright whenever a dialog was active, skipping the freeze-frame path that menus and popovers already use. A dialog now counts as covering the embed, like floating content:
Hiding the view when the pane itself is hidden or the window is backgrounded is unchanged.
Testing
browser-pane.spec.tscomponent suite: 27/27 pass.bun run typecheckinpackages/appandpackages/gui-extensions, oxlint, and prettier pass on the changed files.Requested by: @vimtor (victor via Slack)