fix(developer): handle window already destroyed when closing editor

[mcdurdin]

Fixes: #15617
Fixes: KEYMAN-DEVELOPER-1JD
Fixes: KEYMAN-DEVELOPER-36K
Fixes: KEYMAN-DEVELOPER-2P5
Test-bot: skip

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

Test Artifacts

• Windows
  • Keyman for Windows - build : all tests passed (no artifacts on BuildLevel "build")
  • FirstVoices Keyboards for Windows - build : all tests passed (no artifacts on BuildLevel "build")
  • FirstVoices Keyboards for Windows (old PRs) - build : all tests passed (no artifacts on BuildLevel "build")
  • Keyman for Windows (old PRs) - build : all tests passed (no artifacts on BuildLevel "build")
  • Text Editor (ARM64) - build : all tests passed (no artifacts on BuildLevel "build")
  • Text Editor (x64) - build : all tests passed (no artifacts on BuildLevel "build")
  • Text Editor (x86) - build : all tests passed (no artifacts on BuildLevel "build")

[darcywong00]

lgtm

[ermshiperete]

Do we need the Assigned(cefwp) check in SetFocus as well?

At least that's what devin.ai thinks.

common/windows/delphi/chromium/Keyman.UI.UframeCEFHost.pas:R376

Missing Assigned(cefwp) check in SetFocus causes access violation when cefwp is nil

The PR adds Assigned(cefwp) guards in HasFocus and Handle_CEF_DESTROY to protect against cefwp being nil, but the same guard is missing in SetFocus at line 376. After Handle_CEF_DESTROY runs FreeAndNil(cefwp) at line 579, cefwp becomes nil. If SetFocus is subsequently called (e.g., from Handle_CEF_LOADEND at line 643 via an asynchronously posted CEF_LOADEND message), it will access cefwp.CanFocus on a nil reference, causing an access violation.

Root Cause

The destruction sequence is asynchronous: cefClose posts CEF_DESTROY (line 570), and Handle_CEF_DESTROY frees cefwp via FreeAndNil(cefwp) (line 579). However, other messages like CEF_LOADEND can still be in the message queue. When Handle_CEF_LOADEND (Keyman.UI.UframeCEFHost.pas:634-647) processes, it calls SetFocus at line 643, which accesses cefwp.CanFocus without checking if cefwp is assigned:

if not FIsClosing and cefwp.CanFocus and Assigned(cef) then

The fix in Handle_CEF_SETFOCUS (line 665) already has the correct pattern: if Assigned(cefwp) and cefwp.Visible and cefwp.CanFocus then. The same pattern should be applied in SetFocus.

Impact: Access violation crash when the browser is being destroyed and a load-end or external SetFocus call arrives.