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

Aperta
  • Qualcosa non va?
#29 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp, csharp, dart, flutter
Ambito
backend-api-design, desktop

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
172
Fork
16
Merge medio
40m
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di libnativeapi/nativeapi

Tutte le issue di libnativeapi/nativeapi

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.