3fa5280fdefix: 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. |
||
|---|---|---|
| .. | ||
| app | ||
| browser | ||
| common | ||
| renderer | ||
| services/node | ||
| utility | ||