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

Ouverte
  • Quelque chose ne va pas ?
#29 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
38/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
cpp, csharp, dart, flutter
Domaine
backend-api-design, desktop

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
172
Forks
16
Merge moyen
40 min
PR mergées (30 j)
2

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de libnativeapi/nativeapi

Toutes les issues de libnativeapi/nativeapi

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.