Skip to content

fix(app): keep the browser page under a still while a dialog is open - #58958

Merged
opencode-agent[bot] merged 1 commit into
devfrom
fix/browser-dialog-still
Oct 25, 2026
Merged

opencode-agent[bot] merged 1 commit into
devfrom
fix/browser-dialog-still

Conversation

@opencode-agent

Copy link
Copy Markdown
Contributor

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:

  • On open, the page stays up until its captured still is on screen, then the native view hides and the scrim dims the still.
  • On close, the native view comes back over the still, which stays for a moment until the page has repainted.

Hiding the view when the pane itself is hidden or the window is backgrounded is unchanged.

Testing

  • New component test: opening a dialog keeps the page visible until the still is captured, then shows the still, and closing restores the page. It fails without the fix.
  • browser-pane.spec.ts component suite: 27/27 pass.
  • bun run typecheck in packages/app and packages/gui-extensions, oxlint, and prettier pass on the changed files.
  • Not yet checked in a real desktop build.

Requested by: @vimtor (victor via Slack)

@opencode-agent opencode-agent Bot left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@opencode-agent
opencode-agent Bot merged commit 66a3ed9 into dev Oct 25, 2026
20 checks passed
@opencode-agent
opencode-agent Bot deleted the fix/browser-dialog-still branch October 25, 2026 12:01
@amrkmn amrkmn mentioned this pull request Oct 27, 2026
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant