Closed Bug 1715740 Opened 3 years ago Closed 2 years ago

Dialog windows become fully inaccessible on MacOS after a modal dialog was opened from a modal dialog (e.g. Edit Filter dialog lost behind the main window after an error prevents the filter from being saved).

Categories

(Thunderbird :: Filters, defect, P1)

Product:
Thunderbird
Component:
Filters
Version:
Thunderbird 90
Platform:
x86_64
macOS
Type:
defect

Tracking

(thunderbird_esr91 fixed)

Status:
RESOLVED FIXED
Milestone:
91 Branch
Tracking Flags:
Tracking Status
thunderbird_esr91 --- fixed

People

(Reporter: malcolm, Assigned: KaiE)

References

(Depends on 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

Dialog Window Paradox. The dialog requires attention but I cannot access to address the issue it has raised.
1.97 MB, video/quicktime
Details
"Advanced Edit" dialog makes parent compose message dialog window controls disappear
340.67 KB, image/gif
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.79 Safari/537.36

Steps to reproduce:

Started to create a filter that would copy an email to a local folder. However, I forgot to specify a folder. When I hit the enter button a dialog advised me that I had to specify a target folder.

Actual results:

At that point the title bar of the filter window is visible above the messages window but the rest of the filter window is hidden. It is not possible to access the filter window. the window controls do not respond to mouse clicks. I'm using Mac OS so I used the force quit command. As the application closed, the messages window disappeared and the filter window was visible momentarily.

Expected results:

The filter window should have be rendered above the messages window. Regardless of the window order, the window controls should operate properly. If the window controls worked I would have been able to move them into the correct position.

When the "You must select the target folder" alert message appeared, it blocked the Filter Rules dialog, and couldn't be closed with the "OK" button, so you could select a folder?

Works for me using 90.0b1 on Windows 10.

Flags: needinfo?(malcolm)

When the "You must select the target folder" alert message appeared, the Filter Rules dialog seemed to disappear. I'm not sure if it was an accidental mouse click that caused that.

I noticed that the title bar of the dialog was visible above the main messages window. However, I couldn't select that window, or the messages window. I wasn't able to move the windows to access the dialog. I could access the menus, they displayed but they didn't respond to my selections, i.e., quit.

Glad it's not a universal problem. I'm running on Mac OS 11.4

Flags: needinfo?(malcolm)
OS: Unspecified → macOS
Hardware: Unspecified → x86_64

I've just bumped into a similar problem. A dialog window, "attach image" in this case, alerts me to a problem "Alt text required." But the dialog window is displayed behind the mail window and I'm unable to access it. I have created a short screen grab of the issue that I will add to this report. In the screen grab I've minimised the email message window in the front to allow the dialog behind it to be seen.

Without access to the dialog I cannot correct the alt text issue. I cannot save or close the email message window. Only the dialog has window controls.

This movie shows an image attachment dialog in front of an email message window (reduced in size). The image dialog threw a message saying that an Alt text would be required. But instead of remaining in front of the email message window the dialog displayed behind the email message window. The title of the dialog window was visible. I could reduce the email message window dimensions. I could move the email message window independently to the dialog. If I moved the dialog it would move the email message window with it. I can not enter the email message window. I cannot close it. Nor can I enter or close the dialog.

Severity: -- → S2

Filters and Insert > Image both work for me without being hidden behind the application window on Windows and Fedora 34 Workstation with 90.0b1.

Tried safe mode using Help > Troubleshoot Mode?

Summary: Edit Filter Window is lost behind the main window after an error prevents the filter from being saved. → Dialog windows become fully inaccessible on MacOS after they lost focus to an error alert (e.g. Edit Filter dialog lost behind the main window after an error prevents the filter from being saved).

(In reply to WaltS48 [:walts48] from comment #5)

Filters and Insert > Image both work for me without being hidden behind the application window on Windows and Fedora 34 Workstation with 90.0b1.

Tried safe mode using Help > Troubleshoot Mode?

Flags: needinfo?(malcolm)

Anthony, can you reproduce?

confirming. pure coincidence, I just had this happen to me. Filters UI is unusable, but Thunderbird is not hung - I can access other parts of thunderbird.

Kind of like bug 1609234 / Bug 1425656 - Sometimes modal dialog open at wrong location, sometimes unusable (Mac)

Shutting down I crashed mozilla::dom::workerinternals::RuntimeService::CrashIfHanging bp-7d58691d-8b50-4074-8834-0a8d40210702

Status: UNCONFIRMED → NEW
Ever confirmed: true

We have all sorts of focus fails where focus gets lost into the wrong places. Not all of them may make things completely inaccessible, but still...

See Also: → 1059508, 942610, 708543, 460238, 383634
Flags: needinfo?(malcolm)
See Also: → 1712980
See Also: → 1699514

I'm seeing a different but similar variation of this. I use Filtaquilla to create javascript filters. It includes a button to open a multi-line editing box, because pasting multi-line code into filter terms has, for at least 15 years, altered the values being pasted so that there are commas in the place of every carriage return, which is a syntax error in javascript code.

Since upgrading to TB91, whenever, I open the multiline js editor, suddenly the main filter editing window disappears from behind it, leaving it floating in the air in front of the main Filters dialog. When I close out of the js editor, the Filters dialog is frozen and non-interactive, exactly in the same manner as described by OP.

(In reply to malcolm from comment #3)

A dialog window, "attach image" in this case, alerts me to a problem "Alt text required." But the dialog window is displayed behind the mail window and I'm unable to access it.

I was just about to report this as a separate issue with the "Advanced Edit" dialog, but it turns out this is exactly it.

The situation looks a little different on Mojave (macOS 10.14), because modals still stick out from underneath of the parent window's title bar like a drawer or a tongue or whatever. But I'm left with a message compose window with no window controls, and I can't close it, even with ⌘+W, and at least some of the time I'm unable to close Thunderbird, requiring a force quit.

I will (try to?) attach a GIF animation of what I've just described to the issue.

(I know box-shadow is not an HTML attribute, that was an accident! The behavior is the same, regardless.)

See Also: → 1736846
Severity: S2 → S1
tracking-firefox94: --- → ?
tracking-firefox94: ? → ---
tracking-firefox95: --- → ?
tracking-firefox95: ? → ---
Priority: -- → P1

Additional scenario:

composer window, options check spelling, click "edit", close the edit dialog, now the spelling dialog is behind the composer window and you're stuck.

Steven, if you're around, we could need your in-depth Mac expertise on this cluster which probably have the same root cause!

I still (occasionally) work on macOS-specific Mozilla bugs that interest me -- especially ones that seem likely to be very low level, and to be amenable to my HookCase debugging tool. This one does look interesting. But I'm currently busy with something else (in fact updating HookCase to be compatible with macOS 12 (Monterey)). It'll likely be a week or two before I have any time to spend on this bug.

Of the bugs filed between version 78 and 91, I think the oldest bug 1712980 dated May 2021

See Also: → 1737324, 1609234, 1722948, 1719917

Could we identify the first nightly build that was broken?

deleted

deleted

deleted

Looking at the changes, maybe it's related to bug 1691171.

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

Of the bugs filed between version 78 and 91, I think the oldest bug 1712980 dated May 2021

Even earlier is Bug 1695142 - Master password dialog on startup deadlocks UI - which unfortunately didn't get recognized as a new issue. And see bug 1699514 comment 10 / 11 for more info from dschubert, and which confirm the regression range.

I'm attempting to build comm-esr91 with the older MacOS 10.11 SDK. I'm trying to locally back out patches from mozilla platform that depend on the newer SDK. The intention is to confirm whether the change indeed is inside the SDK or not.

If it's inside the SDK, then we can research if we can potentially switch the TB 91 builds to the older SDK. So far, the only change I've had to back out was more precise timing measurements for telemetry. Let's see if there's more, local build still running.

The SDK isn't the cause.

My attempt from comment 26 didn't succeed. There were too many changes.

Then I changed strategy. I tried to build the broken revision from comment 22. I thought: If the newer 10.12 SDK is the culprit, then I should be able to build that old revision against the old 10.11 SDK, and it should work.

But that attempt failed, too. I couldn't build with the old SDK. Apparently even before that date, several changes were made that already required the newer 10.12 SDK.

During my journey I learned the directory mozilla/widget/cocoa is the area where the macOS windowing code lives. I attempted to build the old broken revision, but in addition, reverting all changes from that directory to the working revision from the day before. That didn't build either.

While waiting for builds, I looked at the patches. One of them looked suspicious to me. And then I got a success. I build the broken revision from comment 22, and only reverted the single patch from bug 1691171. That creates a working build.

I think this regression bug was caused by bug 1691171.
When reverting the patch from bug 1691171, on top the changeset from comment 22 (February 12), the regression is gone.

The patch doesn't cleanly apply to latest comm-esr91, we'll need to find out how to unmerge it, or we need a better fix.

Regressed by: 1691171

Rob, if we wanted to apply a patch to mozilla-esr91, we'd have to start maintaining our own branch of it?

Flags: needinfo?(rob)
Summary: Dialog windows become fully inaccessible on MacOS after they lost focus to an error alert (e.g. Edit Filter dialog lost behind the main window after an error prevents the filter from being saved). → Dialog windows become fully inaccessible on MacOS after a modal dialog was opened from a modal dialog (e.g. Edit Filter dialog lost behind the main window after an error prevents the filter from being saved).
Assignee: nobody → kaie
Status: NEW → ASSIGNED

test binary:
https://kuix.de/mozilla/thunderbird/thunderbird-91.2.x-test1-lockup-1715740.en-US.mac.dmg

Use at your own risk, no guarantees that my mac is free of viruses etc.

sha256sum
cdc8459a1f6edf359d9fe8d31fb1a3ba36c83f0616df3c2930813efd3ae06f76 thunderbird-91.2.x-test1-lockup-1715740.en-US.mac.dmg

Great findings!
Could you launch a try run?
I'm using artifact builds on macOS so I can't apply this patch.

I tested this with your try run and it works. That back-out fixes all the window problems.

See Also: → 1737489

Over the last couple of days multiple users of my add-on Mail Merge reported an issue under macOS with Thunderbird 91, which turned out to be another variation of this bug: Open the Message Compose Window, then open the Mail Merge Dialog, then open the Mail Merge Help Dialog. Once you close the Mail Merge Help Dialog, Thunderbird gets stuck. Instead the Mail Merge Dialog should get focused again.

Today I had time to investigate the problem and was able to reproduce the issue for Mail Merge as well as several of the already mentioned cases for Thunderbird, e.g. filter dialog, spelling dialog and insert link or insert image dialogs.

I can also confirm the try run in comment #31 fixes the problem for the mentioned cases in Thunderbird incl. for my add-on Mail Merge.

Comment on attachment 9247434 [details]
Bug 1715740 - Revert patch from bug 1691171. r=rjl

Revision D129353 was moved to bug 1691171. Setting attachment 9247434 [details] to obsolete.

Attachment #9247434 - Attachment is obsolete: true
See Also: → 1737608

Just to confirm: Both try runs, i.e. comm-central and comm-esr91, work for me!

Depends on: 1737489
See Also: 1737489 →
Assignee: kaie → nobody
Status: ASSIGNED → NEW

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

test binary:
https://kuix.de/mozilla/thunderbird/thunderbird-91.2.x-test1-lockup-1715740.en-US.mac.dmg

Can confirm this test build fixes the problem as I observed it in the Filtaquilla extension's javascript action editor. While you're in the js editing popup, the filter rules window is gone, making it look like when you close the popup you will be stuck, but now, closing the popup reopens the filter rules window, and you can continue with your normal TB usage. And there was much rejoicing.

Flags: needinfo?(rob)

CI build above for version 91 certainly solves the problem for me.

Fixed in Thuderbird 91.3.0

status-thunderbird_esr91: affected → fixed

Bad news: The bug reappeared in all its glory, e.g. filter dialog, spelling dialog and insert link or insert image dialogs, with the recently released Thunderbird 91.3.1. (Thunderbird 91.3.0 is not affected!)

Yes the is a regression in 91.3.1. So 91.3.2 is in the works.

Looking forward to 91.3.2! (Bug confirmed.)

I think this was fixed in 91.3.2 as announced.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Assignee: nobody → kaie
Target Milestone: --- → 91 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: