It seems like removing the rwhv->SetActive calls fixes #19124. However, #18502 persists even with those calls removed.

However, both solutions give less than desirable outcomes for firing focus and blur events. On browser and previous versions of Electron, opening the Character Viewer wouldn't fire either event, since the window's Main status wouldn't change.

With the Key change:

1. Removing rwhv->SetActive fires both focus and blur.
2. This PR's original change only fires focus since the blur event is blocked.

I'm not particularly sure what to do in this case. It seems like removing the rwhv calls gives a more reasonable behavior, though.

cc @zcbenz @nornagon

I think we got confused with 2 types of focus/blur here: one is the focus events of BrowserWindow, the other is the focus events of DOM Window.

For BrowserWindow, the focus events should be main window events, otherwise things like opening spotlight or status item menu would trigger the focus events. For example with PR, while it hacks windowDidResignKey so blur is emitted correctly for some cases, opening and closing spotlight would still tigger focus on BrowserWindow, and I don't think we can cover all edge cases.

For DOM Window, the focus events, which are controlled by SetActive or StoreFocus/RestoreFocus, should be key window events, as investigated by @erickzhao and @nornagon.

So to correctly fix both issues without breaking focus events of BrowserWindow, I think we should:

1. Still call OnWindowBlur/OnWindowBlur(which emits focus/blur on BrowserWindow) on main window events.
2. Call SetActive on key window events, with check in windowDidResignKey.
3. Call StoreFocus/RestoreFocus on main window events. (Chrome calls them on tab change, which seems to map to the main window events, it needs some testing to confirm.)

We would need to add more methods to NativeWindowObserver to handle key window events separately instead of keeping everything in OnWindowBlur/OnWindowBlur.

@zcbenz @codebytere @nornagon do you think that we should first move to revert the original change? PR #18995 was backported to 6, 5, and 4, and it seems like this issue is more immediately pressing for macOS users than the modal focus behavior.

Reverting #18995 first sounds good to me.

Going to close this and attempt to resolve #18502 in a future PR as per the comments above.