Open Bug 1870660 Opened 9 months ago Updated 6 months ago

Implement file picker close for Win32

Categories

(Core :: Widget: Win32, task)

task

Tracking

()

People

(Reporter: canadahonk, Assigned: rkraesig)

References

Details

No description provided.
Assignee: nobody → rkraesig
Depends on: 1869053
Blocks: 1837008

This is going to be much more difficult than expected. Despite initial tests going well, IFileDialog::Close() isn't usable cross-thread once the dialog has opened. It might be usable from the same thread with a dummy window, but the only examples I have of it working are from use within IFileDialogCustomize implementations.

That does at least break the dependency on AgileReference, though.

No longer depends on: 1869053
No longer blocks: 1837008

Unfortunately, I have been unable to find any safe way to close a Windows file-dialog except by terminating its host process.

Windows file dialogs may spawn arbitrary modal child dialogs which have no programmatic close mechanism (most notably the overwrite-confirmation dialog; but third-party shell extensions may spawn others), so even sending WM_CLOSE directly is not sufficient. (::DestroyWindow or ::TerminateThread might work, but would likely leave the host process in a bad state.)

I don't think nsFilePicker can safely implement a general-purpose Close() method until both a) we have transitioned entirely to the out-of-process file-picker, and b) we have isolated file-pickers from each other in different processes. (At present, due to limitations of our utility-process framework, all out-of-process file-pickers open in the same process. I don't have an estimate of how much work will be needed to change that, but it's likely quite a bit.)

Documentary follow-up, to be explicit:

(In reply to Ray Kraesig [:rkraesig] from comment #1)

It might be usable from the same thread with a dummy window

It's not. Calling it in this context does exactly nothing.

You need to log in before you can comment on or make changes to this bug.