2053177 - nsIFilePicker invokes callback before another modal can be safely launched

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Justin Tracey [:jtracey]]

In bug 2052844, Thunderbird is seeing a new behavior on macOS 25 ("new" with the OS version, not "new" with an application update) where launching another dialog immediately after the callback for filePicker.open resolves causes the application to hang. Adding an await new Promise(resolve => Services.tm.dispatchToMainThread(resolve)); line between them makes the problem disappear, which makes me suspect something is causing the callback to invoke when the file is chosen instead of when the modal is fully unwound. We can work around it in the meantime, but I suspect this is something that should be fixed more generally.

Comment 1

[Stephen A Pohl [:spohl] (OOO until 7/30, contact :haik if urgent)]

Attachment: Bug 2053177: Defer the macOS file picker callback until the modal has unwound. r?#mac-reviewers!

On macOS 26, the NSSavePanel/NSOpenPanel sheet completion handler can run before the panel's modal session has fully unwound. We invoke nsIFilePickerShownCallback::Done() synchronously from inside that completion handler, so a consumer that opens another modal from Done() (for example Thunderbird's "Backup Secret Key to File" flow in bug 2052844) starts the new modal on top of a session that is still tearing down, which hangs.

Defer Done() to a fresh main-thread turn in all four picker modes (open, open-multiple, folder, save) so the modal finishes unwinding first. This matches the JS-side workaround of bouncing off Services.tm.dispatchToMainThread before launching the next modal, but fixes it once for every file-picker consumer. The callback still runs on the main thread exactly once with the same ResultCode; only its timing moves one turn later.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/74a71a4f0991
https://hg.mozilla.org/integration/autoland/rev/2a30e91b0728
Defer the macOS file picker callback until the modal has unwound. r=mac-reviewers,mstange,jtracey

Comment 3

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/2a30e91b0728

Comment 6

[Magnus Melin [:mkmelin]]

Apparently this is affecting 153 (and even earlier) versions too (when they get the OS update). Can we uplift?

Comment 7

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Opening a second file picker dialog can cause a hang.
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: This simply defers invoking filepicker callbacks to another main thread turn.
• String changes made/needed?: none
• Is Android affected?: no

Comment 8

[Stephen A Pohl [:spohl] (OOO until 7/30, contact :haik if urgent)]

Attachment: Bug 2053177: Defer the macOS file picker callback until the modal has unwound.

On macOS 26, the NSSavePanel/NSOpenPanel sheet completion handler can run before the panel's modal session has fully unwound. We invoke nsIFilePickerShownCallback::Done() synchronously from inside that completion handler, so a consumer that opens another modal from Done() (for example Thunderbird's "Backup Secret Key to File" flow in bug 2052844) starts the new modal on top of a session that is still tearing down, which hangs.

Defer Done() to a fresh main-thread turn in all four picker modes (open, open-multiple, folder, save) so the modal finishes unwinding first. This matches the JS-side workaround of bouncing off Services.tm.dispatchToMainThread before launching the next modal, but fixes it once for every file-picker consumer. The callback still runs on the main thread exactly once with the same ResultCode; only its timing moves one turn later.

Original Revision: https://phabricator.services.mozilla.com/D310869

Comment 9

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: Opening a second file picker dialog can cause a hang.
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: This simply defers invoking filepicker callbacks to another main thread turn.
• String changes made/needed?: none
• Is Android affected?: no

Comment 10

[Stephen A Pohl [:spohl] (OOO until 7/30, contact :haik if urgent)]

Attachment: Bug 2053177: Defer the macOS file picker callback until the modal has unwound.

On macOS 26, the NSSavePanel/NSOpenPanel sheet completion handler can run before the panel's modal session has fully unwound. We invoke nsIFilePickerShownCallback::Done() synchronously from inside that completion handler, so a consumer that opens another modal from Done() (for example Thunderbird's "Backup Secret Key to File" flow in bug 2052844) starts the new modal on top of a session that is still tearing down, which hangs.

Defer Done() to a fresh main-thread turn in all four picker modes (open, open-multiple, folder, save) so the modal finishes unwinding first. This matches the JS-side workaround of bouncing off Services.tm.dispatchToMainThread before launching the next modal, but fixes it once for every file-picker consumer. The callback still runs on the main thread exactly once with the same ResultCode; only its timing moves one turn later.

Original Revision: https://phabricator.services.mozilla.com/D310869

Comment 11

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/f845294820b2
https://hg.mozilla.org/releases/mozilla-beta/rev/a2943824ee61

Comment 12

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/452e8b8171b0
https://hg.mozilla.org/releases/mozilla-release/rev/42d6505b02d7

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Added to the 152.0.6 relnotes.