Open Bug 1699514 Opened 7 months ago Updated 11 days ago

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

Categories

(Thunderbird :: Mail Window Front End, defect)

Thunderbird 87
Unspecified
macOS
defect

Tracking

(thunderbird_esr78 unaffected, thunderbird_esr91+ affected, thunderbird87 wontfix, thunderbird91 wontfix, thunderbird93 wontfix, thunderbird94 affected)

Tracking Status
thunderbird_esr78 --- unaffected
thunderbird_esr91 + affected
thunderbird87 --- wontfix
thunderbird91 --- wontfix
thunderbird93 --- wontfix
thunderbird94 --- affected

People

(Reporter: jmccabe, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug, Regression, )

Details

(Keywords: hang, regression, reproducible, Whiteboard: [bmoquery: https://mzl.la/39C33Zk])

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.

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)

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

Severity: -- → S3
Status: UNCONFIRMED → NEW
Component: Untriaged → Mail Window Front End
Ever confirmed: true
OS: Unspecified → macOS
Summary: Saved Search window loses focus → Saved Search properties window loses focus, cannot be closed

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

Summary: Saved Search properties window loses focus, cannot be closed → [macOS] Saved Search properties window loses focus, cannot be closed
Duplicate of this bug: 1705841

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)

Severity: S3 → S2
Flags: needinfo?(calum.mackay)
Keywords: hang, reproducible
Summary: [macOS] Saved Search properties window loses focus, cannot be closed → [macOS] Saved Search properties window loses focus, cannot be closed, Thunderbird hangs

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.

(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

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.

Flags: needinfo?(calum.mackay)
Depends on: 530608

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.

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?

Flags: needinfo?(rob)
Regressed by: 1691988

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?

Flags: needinfo?(rob) → needinfo?(alessandro)

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

Flags: needinfo?(alessandro)
Duplicate of this bug: 1717826
Duplicate of this bug: 1732387
Duplicate of this bug: 1729234
Duplicate of this bug: 1707029
Summary: [macOS] Saved Search properties window loses focus, cannot be closed, Thunderbird hangs → [macOS] Saved Search or Unified properties, or create or edit saved search window loses focus, cannot be closed, Thunderbird hangs
Whiteboard: [bmoquery: https://mzl.la/39C33Zk]

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

Blocks: tb91found
Flags: needinfo?(alessandro)
See Also: → 1715740
Duplicate of this bug: 1732806
Duplicate of this bug: 1732950

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.

Flags: needinfo?(alessandro)

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

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