Bugzilla

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 do not have an estimate of how much work will be needed to change that, but it's likely quite a bit.)

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.)