[Windows] Owned file dialogs stall for 20–30 seconds: synchronous cross-thread property reads during WinEvent handling

Start with src/platform/windows/window_windows.cpp:1074, src/window_property_dispatch.cpp:33–37, and the four marshalled getters identified in the issue; then trace OnWindowThread in src/platform/windows/window_docking_windows.h:54. Reproduce with an owned file dialog using lockParentWindow: true and compare with false. Done when owned dialogs appear promptly while retaining owner-relative modality and the cross-thread wait no longer stalls.

Description

Opening a native Save File dialog stalls for approximately 20 seconds after upgrading from window_manager 0.5.2 to 0.6.0, which introduces nativeapi / cnativeapi.

Thread dumps captured during the delay show the platform thread waiting inside cnativeapi while the dialog thread is inside NtUserSetFocus. Source inspection and disassembly identify synchronous cross-thread property reads with individual five-second timeouts.

Setting WindowsOptions(lockParentWindow: false) eliminates the delay in the tested application. Switching the same diagnostic binary back to true restores it.

Environment

• Windows 11, build 22621.4317, x64.
• Flutter 3.47.9, release AOT build.
• window_manager: 0.6.0
• nativeapi / cnativeapi: 0.5.10
• file_picker: 13.3.2
• windows_file_picker: 2.0.1

Users originally reported the problem on Windows 10. The measurements and thread dumps below were collected on Windows 11; Windows 10 was not independently tested.

Reproduction

In an application using window_manager, open a save dialog through file_picker with lockParentWindow: true, cancel it, and repeat. Compare against false, including after restarting the process.

The relevant call pattern is:

await FilePicker.saveFile(
  fileName: 'settings.json',
  bytes: bytes,
  windowsOptions: WindowsOptions(
    lockParentWindow: true, // Compare with false.
  ),
);

This is a reduced illustration of the tested application’s call, not an independently verified standalone reproduction.

windows_file_picker opens the COM dialog from a separate Dart isolate. With true, it supplies an owner HWND to IFileDialog::Show; with false, it supplies no owner.

Expected: the dialog appears promptly while preserving its ownership and modal behavior.

Actual: the owned dialog takes tens of seconds to appear.

A/B results

Configuration	Observation
Previous application release using window_manager 0.5.2	Dialog visible within 0.50–0.59 s
Current official release, lockParentWindow: true	Absent at 19.17/19.18 s; visible at 20.61/20.49 s
Diagnostic build, false, repeated invocation	Absent at 0.232 s; visible at 0.358 s
Same diagnostic build, false, first invocation after restart	Absent at 0.233 s; visible at 0.359 s
Same diagnostic build, switched back to true, repeated invocation without debugger	Absent at 28.44 s; visible at 30.53 s

The diagnostic build retained the official application’s executable and native DLLs, including cnativeapi.dll and flutter_windows.dll. Only the Dart AOT payload was rebuilt to override and log the option. The same AOT payload was used for both values.

These are observation bounds measured from the click, including automation overhead. A separate screenshot-only check also reproduced the delay, without UI Automation tree polling. All dialogs were cancelled.

Thread stacks during the delay

The original release was captured using CDB noninvasive attachment. Windows frames were resolved using Microsoft symbols.

Platform thread, abbreviated, current frame first:

ntdll!NtWaitForAlertByThreadId+0x14
ntdll!RtlSleepConditionVariableSRW+0x13b
KERNELBASE!SleepConditionVariableSRW+0x29
cnativeapi+0xc6fd8
cnativeapi+0xad45a
cnativeapi+0x28ab3
cnativeapi+0x28b95
cnativeapi+0xb0d7d
... cnativeapi WinEvent handling frames ...
user32!_ClientCallWinEventProc+0x46
ntdll!KiUserCallbackDispatcherContinue
win32u!NtUserGetMessage+0x14
user32!GetMessageW+0x2a

Dialog thread, abbreviated:

win32u!NtUserSetFocus+0x14
shell32!CSaveControlsModuleInner::_CreateControls+0x4d9
shell32!CSaveControlsModuleInner::SetSite+0x53
shell32!CSaveControlsModule::LayoutInitialized+0x49
... shell layout / ExplorerBrowser initialization ...
comdlg32!CFileOpenSave::_JumpToInitialLocation+0x1b7
comdlg32!CFileOpenSave::_InitOpenSaveDialog+0xc5f
comdlg32!CFileOpenSave::s_OpenSaveDlgProc+0x278
... user32 dialog creation ...
comdlg32!CFileOpenSave::Show+0xe92

With false, a control dump taken after the dialog appeared showed the platform thread normally waiting in:

win32u!NtUserGetMessage+0x14
user32!GetMessageW+0x2a

Identified blocking path

Inspection of the source shipped with cnativeapi 0.5.10, combined with disassembly, reconstructs this path:

WinEvent callback on the platform thread
  -> WindowManager wraps the dialog HWND
  -> Window::Window(void*)
  -> WindowPropertyDispatch::Refresh
  -> Read
  -> cross-thread property getter
  -> detail::OnWindowThread
  -> PostToThread(dialog thread, ...)
  -> condition_variable wait

Relevant source locations in that package:

• src/platform/windows/window_windows.cpp:1074: the Window constructor calls WindowPropertyDispatch::Refresh.
• src/window_property_dispatch.cpp:33–37: reads IsMinimizable, IsMaximizable, IsClosable, and IsWindowControlButtonsVisible.
• src/platform/windows/window_windows.cpp:1827,1857,1898,1931: those getters marshal work to the HWND-owning thread.
• src/platform/windows/window_docking_windows.h:54: OnWindowThread waits up to five seconds for the posted task.

The platform thread therefore waits for work on the dialog thread while that thread is inside focus initialization for an owned window. This strongly indicates a circular dependency involving the owner/platform thread. The kernel-side dependency itself was not traced.

Four sequential five-second timeouts explain the usual approximately 20-second delay.

Additional stack samples, approximately five seconds apart, captured successive waits:

Return address in cnativeapi.dll	Property read
+0x28ab3	IsMaximizable
+0x28ac9	IsClosable
+0x28ad4	IsWindowControlButtonsVisible

These internal C++ names were reconstructed from source and disassembly, not resolved from a private PDB. The additional delay in the 30-second run was not individually traced.

Workaround and requested fix

lockParentWindow: false avoids the stall, but removes owner-relative modality, so it changes application behavior.

Could the WinEvent/window-registration path avoid synchronously waiting for another window-owning thread while refreshing properties? The desired behavior is to keep owned file dialogs responsive without requiring applications to disable modality.