fix(main): exit fullscreen before hiding a window on macOS#26
Merged
Conversation
loc
approved these changes
Jul 6, 2026
On macOS, hiding a window that is in native fullscreen (or mid fullscreen transition) doesn't work: the orderOut is swallowed and the window comes back visible with mangled bounds once the transition settles. Pool windows hit this whenever the OS adopts a freshly shown window into a fullscreen space (or the user fullscreens one via the green button) and it is later released. The release prop reset can't help because currentProps.fullscreen never tracks native transitions, and isFullScreen() alone can't be trusted either: a bounds write on a fullscreen window kicks off a leave transition that already reports false while still in flight. Track the native state from the enter/leave-full-screen events the instance already listens to, and make WindowInstance.hide() on macOS exit fullscreen and complete the hide once leave-full-screen fires. Repeated hides arm a single deferred hide, show() cancels a pending one so a window re-shown mid-transition stays visible, and the forced exit is written back to currentProps.fullscreen so a later fullscreen:true update isn't skipped as unchanged. The hideOnClose interception and the visible:false prop path now route through hide() so every hide path gets the same treatment; other platforms keep the direct hide.
codebytere-ant
force-pushed
the
fix/fullscreen-hide
branch
from
a611dc9 to
a7f19c5
Compare
|
🎉 This PR is included in version 1.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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.
On macOS,
BrowserWindow.hide()on a window that is in native fullscreen (or mid fullscreen transition) doesn't take: the orderOut is swallowed while AppKit collapses the fullscreen space, and the window comes back visible with mangled bounds once the transition settles. Pool windows hit this whenever macOS adopts a freshly shown window into an active fullscreen space (or the user green-buttons one) and it's later released. The release prop reset can't help becausecurrentProps.fullscreennever tracks native transitions, andisFullScreen()can't be trusted at hide time either: a bounds write on a fullscreen window starts a leave transition that already reportsfalsewhile still in flight. The result is a stranded, blank, still-visible pool window.This tracks native state from the
enter/leave-full-screenevents the instance already listens to, and makesWindowInstance.hide()on macOS exit fullscreen and complete the hide onceleave-full-screenfires. Repeated hides arm a single deferred hide,show()cancels a pending one (so a pooled window re-acquired mid-transition isn't hidden out from under its consumer), and the forced exit is written back tocurrentProps.fullscreenso a laterfullscreen: trueupdate isn't skipped as unchanged. ThehideOnCloseclose interception and thevisible: falseprop path now route throughhide(); other platforms keep the direct hide. Verified against a real pooled popout on macOS: before, releasing a fullscreen-adopted window leaves it visible and blank; after, it exits fullscreen, hides, and the pool reuses it normally. Unit tests cover the fullscreen, mid-transition, repeat-hide, show-cancel, prop-reapply, and non-mac paths.One known limit: a window that is fullscreen but not fullscreenable never gets
leave-full-screen, so its deferred hide waits until the nextshow().