Electron Releases

Description of Change

Fixes #31917.
Fixes #40212.
Fixes #50647.

After this change typing works again immediately after an alert(), confirm() or beforeunload prompt is closed on Windows; today the caret disappears and characters are dropped (Backspace still works) until the window is deactivated and reactivated.

While such a prompt is open, content marks the renderer as blocked and RenderWidgetHostViewAura ignores focus gains for it. Electron shows the prompt as a native dialog owned by the window, and closing it re-activates the window before the result is delivered, so the view ends up focused in aura but blurred in Blink with no IME client: WM_KEYDOWN arrives, WM_CHAR is dropped. Anything an app does during will-prevent-unload that moves activation has the same effect.

The dialog-closed callback now checks, once the result has unblocked the renderer, whether the view holds aura focus while the widget host is not focused, and if so clears and re-gives focus, replaying the skipped GotFocus and IME attach; nothing happens when they agree, and <webview> guests are skipped. Verified on a Windows 11 VM with real keyboard input, stock 44.4.3 as control and this branch's CI build as test: after dismissing alert() or confirm(), control has document.hasFocus() false and delivers keydown but no keypress (typed text does not appear, Backspace does) until the window is reactivated; the test build has focus and the caret back immediately and typed text appears, including when the window is deactivated while the dialog is open. It does not reproduce under Xvfb because X11 activation is asynchronous; a win32-only spec re-activates the window from a will-prevent-unload handler and expects document.hasFocus().

Checklist

• I have built and tested this change
• I have filled out the PR description
• I have reviewed and verified the changes
• tests are changed or added

Release Notes

Notes: Fixed typing not working after closing an alert() or confirm() on Windows.