1699514 - [macOS] Saved Search or Unified properties, or create or edit saved search window loses focus, cannot be closed, Thunderbird hangs

Status: RESOLVED DUPLICATE of bug 1715740

(Thunderbird :: Mail Window Front End, defect)

Description

[Joe McCabe]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Control-click on Saved Search
Select Properties
Select "Choose" to right of "Select the folders to search"
Click "Cancel" (or otherwise close this second window)

Actual results:

The original Saved Search properties window is drawn unfocused behind the main window. No use input can be provided to either window. Thunderbird must be forced-quit and relaunched.

Expected results:

The original Saved Search properties window should be drawn and have focus. User should be able to interact with the window and, eventually, to dismiss it.

Comment 1

[Joe McCabe]

Note:
Thunderbird 87b3
macOS 11.3 Beta (20E5210c)

Triggering the window focus behavior seems to require a second Thunderbird window being opened, then dismissed (hence the "Choose" step)

Comment 2

[Wayne Mery (:wsmwk)]

I can confirm this.
The hidden window is listed in the Window menu, but it cannot be accessed.
I didn't find any related reports created in the last 30 days

Comment 3

[Joe McCabe]

May be related to recent changes in Firefox. I've seen the same behavior with the Firefox Master Password dialog box if I manage to get multiple stacked prompts to enter it (e.g. reopen Firefox with many, many tabs in the active state that will require authentication prompts on restart).

Comment 5

[Wayne Mery (:wsmwk)]

Alice doesn't have a Mac, so someone will need to run https://mozilla.github.io/mozregression/ to find the one day regression range.
Easily reproduced.

Calum, does this reproduce for you on nightly? (I haven't tested nightly)

Comment 6

[Alessandro Castellani [:aleca]]

This happens also on nightly.

Do we have anyone with a pre-BigSur version of macOS to test this?
I have a weird feeling that this is due to how macOS BigSur handles multiple popup dialogs.
When using this it can be seen the Properties dialog getting closed before the Choose folder dialog is spawned, and then when closing the Choose Folder dialog, the whole application flashes for a second and the properties dialog appears understand.

It almost looks like the whole app/main tab is opened as a dialog of the folder properties dialog.
Super weird.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to Alessandro Castellani [:aleca] from comment #6)

This happens also on nightly.

Do we have anyone with a pre-BigSur version of macOS to test this?

I'm still on 10.15. So it's not specific to big sur

Comment 8

[Calum Mackay]

Yup, confirmed on Daily 0416. MacOS 10.15.7 (19H524)

I don't see the badly-drawn window, but it is in the window list. The window I created it from is badly hosed; mouse scroll responds, but no kbd or mouse click response.

Interestingly, another window I had open remains fine, and I can open new windows fine.

But the window from which the search was accessed is stuck. Even the three Mac window icons in the top left have disappeared from it; never seen that before.

Comment 9

[Dennis Schubert [:denschub]]

Updating tracking fields as I can reliably reproduce this on macOS 11.5.1 in Release 91.0, Beta 91.0b6, and Daily 93.0a1.

Comment 10

[Dennis Schubert [:denschub]]

Last good revision: b5009973dfb0e04c91dd1cfa7260506f64d88e98
First bad revision: b4662538ede6e2a9e9686f10806138ca84a3b3e7
Pushlog: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=b5009973dfb0e04c91dd1cfa7260506f64d88e98&tochange=b4662538ede6e2a9e9686f10806138ca84a3b3e7

Which is only bug 1691988 - which is a buildchain/SDK change. So that's fun.

Rob, any ideas?

Comment 11

[Rob Lemley [:rjl]]

That push should have built with https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=1941f4130b28b8b5863b2af402602d3ef5614d5e.
The regression is likely among those changes.

Besides the macOS SDK change (bug 1685764), there is bug 1691213 that is updating some native menu code, and bug 1686946 which enabled webrender on beta and nightly. None of those really stand out.

What's interesting is a subsequent mozilla-central push: https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=f0ff491c99ca7c4fd6dafb191704930f6f8a34b9

Bug 1685313 works on modal dialogs and "disable[s] menus, commands, and tabswitches while window-modal dialogs are up". I suspect that what you're seeing is a modal dialog that isn't getting set up correctly but still manages to disable input to other windows. Maybe Alessandro can confirm that?

Comment 12

[Alessandro Castellani [:aleca]]

Bug 1685313 works on modal dialogs and "disable[s] menus, commands, and tabswitches while window-modal dialogs are up". I suspect that what you're seeing is a modal dialog that isn't getting set up correctly but still manages to disable input to other windows. Maybe Alessandro can confirm that?

I'm not really sure what's going on here unfortunately.
I tested TB without the changes of Bug 1685313 and the issue still remains.

We're opening a dialog from withing a dialog, and when the second dialog is closed, the original dialog is not properly reopened as I think macOS doesn't actually closes the first dialog, but simply "hides" it.

Maybe this is indeed an SDK issue? (uneducated guess).

Comment 17

[Wayne Mery (:wsmwk)]

perhaps related Bug 1712980 - Mail Window unresponsive after startup with primary/master password (dialog) enabled (macOS)

Comment 20

[Alessandro Castellani [:aleca]]

I really don't know how to fix this other than dropping the various "dialogs within dialogs" paradigm.
We should maybe consider having the folder properties inside an HTML dialog.

Comment 21

[Tobias H [:tobiash]]

The same bug occurs in the following dialogs as well.

Selecting mail folders to be downloaded for the Offline mode:
"File -> Offline -> Download/Sync Now...", click on "Select...", close dialog ("Cancel" or "OK"), Thunderbird is unresponsive

Adding a new OpenPGP key:
"Tools -> OpenPGP Key Manager", then "File -> Import Secret Key(s) From File", click on "Select File to Import...", click on "Continue", enter passphrase, Thunderbird is unresponsive

Comment 22

[Wayne Mery (:wsmwk)]

Users who are on beta, please test https://archive.mozilla.org/pub/thunderbird/candidates/94.0b5-candidates/build1/ and post your results. Thanks in advance.

Comment 23

[Tobias H [:tobiash]]

The beta release fixes the bug for me in all mentioned cases (selecting folders for saved search, selecting folders for unified folders, selecting folders for offline mode, and importing an OpenPGP key with a passphrase).
Thanks for fixing it!

Comment 24

[Michael]

Beta works for me as well (i.e. I was able to include another email folder into an existing, local search for "starred" emails). Thanks!

Comment 25

[Joe McCabe]

Users who are on beta, please test https://archive.mozilla.org/pub/thunderbird/candidates/94.0b5-candidates/build1/ and post your results.

Result: Works as expected. Thanks!

Any chance you can push whatever change this is over to Firefox as well?

Comment 26

[Magnus Melin [:mkmelin]]

If you have a case where it's broken in Firefox we'd be very eager to know the steps to reproduce there!

Comment 27

[Joe McCabe]

(In reply to Magnus Melin [:mkmelin] from comment #26)

If you have a case where it's broken in Firefox we'd be very eager to know the steps to reproduce there!

Exactly this one ( 1712980 ) except in Firefox. If multiple Master Password dialog boxes are triggered then one of them will become attached/stacked behind the parent window and not be able to be interacted with. Firefox must be force-quit, and the the user must aggressively cancel the Master Password boxes as they open and before they can stack. This behavior can be triggered by having multiple tabs/browser windows open that will need access to the password store, and then restart Firefox. As it reloads the prior state the different tabs/windows will trigger their own Master Password prompt. The video in 1712980 (a Thunderbird bug) shows the behavior.

Comment 28

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #22)

Users who are on beta, please test https://archive.mozilla.org/pub/thunderbird/candidates/94.0b5-candidates/build1/ and post your results. Thanks in advance.

Looks sorted by my reckoning as well... no issues with the testing

Comment 29

[Wayne Mery (:wsmwk)]

91.3.0 should have the fix this week. Thanks for all the feedback.

Comment 30

[Kai Engert (:KaiE:)]

I've tried the steps from comment 27. I cannot reproduce using Firefox 91 on macOS.

Comment 31

[Kai Engert (:KaiE:)]

to clarify, I tried to trigger the bug, but I cannot get Firefox to open two password prompts in the same window. If I have multiple windows, I can get it to open a master password prompt in each window. But canceling those dialogs doesn't result in a lockup. I also tried to have a "web site basic auth" popup prompt being shown (that's the classic way to log into password protected websites), but that doesn't help either.

For me, when I restore a session, and two tabs in the same window require access to the password store, then only one of the tabs is loaded immediately. The other one isn't loaded until I cancel the master password prompt and switch to the second tab. Because of the delayed loading, I don't get two password prompts in the same window, so I cannot reproduce stacking them.

Comment 32

[Joe McCabe]

(In reply to Kai Engert (:KaiE:) from comment #31)

to clarify, I tried to trigger the bug, but I cannot get Firefox to open two password prompts in the same window. If I have multiple windows, I can get it to open a master password prompt in each window. But canceling those dialogs doesn't result in a lockup. I also tried to have a "web site basic auth" popup prompt being shown (that's the classic way to log into password protected websites), but that doesn't help either.

For me, when I restore a session, and two tabs in the same window require access to the password store, then only one of the tabs is loaded immediately. The other one isn't loaded until I cancel the master password prompt and switch to the second tab. Because of the delayed loading, I don't get two password prompts in the same window, so I cannot reproduce stacking them.

Agreed. A simple test with a fresh profile seems unable to repro. I don't know if Firefox incidentally fixed the issue too, or if the test case is just tougher to trigger than expected. When I used to regularly trigger it I had 10+ windows, each with ≥5 tabs, any of which might have triggered at least one Master Password prompt. If I did not dispose of the prompt quickly enough (either entering the password, or hitting Cancel) then a second prompt would appear and shortly thereafter the first prompt would become bound to the parent window as demonstrated in that video of the Thunderbird focus bug.

I can't trigger it artificiality, you can't either, and it's a Firefox issue. We can take discussion of it elsewhere if you like. As far as I'm concerned THIS issue (the Thunderbird one against which this bug is tracking) is dealt with.

Comment 33

[Wayne Mery (:wsmwk)]

Thanks for the feedback.

Password related stuff that still occurs can be tracked in bug 1712980 and others