mirror of
https://github.com/electron/electron.git
synced 2026-05-02 03:00:22 -04:00
3fa5280fde
fix: re-enable MacWebContentsOcclusion with embedder window fix (#50579) * fix: re-enable MacWebContentsOcclusion with embedder window fix Replace the full revert of Chromium's MacWebContentsOcclusion cleanup with a targeted patch that handles embedder windows shown after WebContentsViewCocoa attachment. This lets us drop the feature flag disable in feature_list.cc and re-enable upstream occlusion tracking. Adds tests for show/hide event counts on macOS and visibility tracking across multiple child WebContentsViews. * test: drop show/hide event count assertion The assertion that 'show' fires exactly once per w.show() call is not an API guarantee - macOS can send multiple occlusion state notifications during a single show() when other windows are on screen (common on CI after hundreds of prior tests). The visibilitychange-count test in api-web-contents-view-spec.ts covers the actual invariant we care about. * fix: ignore WebContentsOcclusionCheckerMac synthetic notifications in window delegate On macOS 13.3-25.x, Chromium's occlusion checker enables manual frame-intersection detection and posts synthetic NSWindowDidChangeOcclusionStateNotification tagged with its class name in userInfo. These fire when the checker's NSContainsRect heuristic decides a window is covered by another window's frame, but the real -[NSWindow occlusionState] hasn't changed. Our delegate was treating these the same as real macOS notifications and emitting show/hide events based on occlusionState, which was unchanged - resulting in spurious duplicate show events when e.g. Quick Look opened and its frame intersected the BrowserWindow.