Open Bug 1425656 Opened 2 years ago Updated 6 months ago
Sometimes modal dialog open at wrong location, sometimes unusable (Mac)
Modal dialogs on macOS should open as "sub-window" under the title bar of a window. However, since TB 58, the dialogs appear at weird locations. As they cannot be used, the become unusable. See attached screenshot: the Account Manager is opened at the bottom of the window.
I can't reproduce this with 58.0b2. Have you tried with "Restart with Add-ons disabled"?
Yes, it also happens in Safe Mode. I should add that I'm on macOS 10.12.6 (Sierra). It doesn't happen always, and interestingly, it seems to depend on which element got the focus before a dialog is opened. For example, if I click on the message view pane (lower right), then the dialog will open there. Furthermore, the dialog also "moves" when you resize the window. I created a video showing the behavior. It also happens when the dialog is originally at the correct location: https://enigmail.net/video/Screen_Video.mov
Antony, Albert Do you use engimail? If so, do you see this with 58 on Sierra?
AFAICT, it's not depending on Enigmail in any way. I made the video in Safe Mode, without _any_ addon.
Yes, when I marked something in the message pane and then open the prefs through the menu I can confirm your issue on TB 58. On TB 59 the sheet always opens at the correct position. But when resizing the window it jumps too.
Hi Wayne No I mainly use TB std, I believe and I am still using El C. for my OS :-/ Ciao Antony
(In reply to Wayne Mery (:wsmwk) from comment #3) > Antony, Albert > Do you use engimail? If so, do you see this with 58 on Sierra? No Enigmail and El Capitan (for the time being). Sry.
I can reproduce this on High Sierra (macOS 10.13) and with TB 59a1.
Frankie, do you know of anything comparable happening in Firefox? Looking at https://mzl.la/2I9Dxv2 I don't see anything that matches up
No, I've never seen FF Mac display dialogs or sheets at the bottom of the window. Patrick, have you changed your screen resolution?
No, I'm using the standard (high) resolution on my Mac. But I actually don't recall when Firefox would have last displayed a native modal dialog other than the prompt for the master password. AFAICT most FF dialogs seem to be implemented via a semi-transparent layer on top of the main window.
Hard to believe we're not seeing lots of reports about this.
I actually see this issue randomly with Thunderbird 60.0b7 in three different profiles but I am unable to reproduce it deliberately. I also remember having observed it randomly with the TB 59 betas. When it happens the account settings sub-window is functional and I can resize it if I want (see attachment)
Can you narrow the regression range to something smaller in the 58.0a1 range? between https://archive.mozilla.org/pub/thunderbird/nightly/2017/09/2017-09-24-03-02-11-comm-central/ and https://archive.mozilla.org/pub/thunderbird/nightly/2017/11/2017-11-13-03-02-02-comm-central/
Summary: Modal dialog open at wrong location → Intermittent modal dialog open at wrong location, sometimes unusable
(In reply to Wayne Mery (:wsmwk) from comment #15) > Can you narrow the regression range to something smaller in the 58.0a1 > range? > between > https://archive.mozilla.org/pub/thunderbird/nightly/2017/09/2017-09-24-03-02- > 11-comm-central/ I can't find any Mac version on this page > and > https://archive.mozilla.org/pub/thunderbird/nightly/2017/11/2017-11-13-03-02- > 02-comm-central/ In my tests with 58.0a1 version from Nov 13th, 2017 I don't see this issue.
There was actually b1 on Nov 27 and b2 on Dec 10. https://www.thunderbird.net/en-US/thunderbird/58.0beta/releasenotes/ It would be good to determine whether b1 also fails. fixes marked as MacOS in the time perid Nov 13 to dec 10 https://mzl.la/2JH7EOD
In my new tests the issue is not present in TB 57.0b2 from November 18th, 2017 but it is present in TB 58.0b1 from November 27th, 2017. Tell me wether I should test other Nightly versions and which ones.
So you would want to test between https://archive.mozilla.org/pub/thunderbird/nightly/2017/11/2017-11-24-03-02-02-comm-central/ and https://archive.mozilla.org/pub/thunderbird/nightly/2017/11/2017-11-13-03-02-02-comm-central/
Finally a new test with the Nightly 58.0a1 from Nov 13, 2017 showed that the issue was already present at that date although I couldn't prove it in my first test. Then I tested from https://archive.mozilla.org/pub/thunderbird/nightly/2017/11/2017-11-13-03-02-02-comm-central/ backwards until https://archive.mozilla.org/pub/thunderbird/nightly/2017/10/2017-10-26-03-02-01-comm-central/ and the issue could be seen in all intermediate versions. I could not reproduce the issue in Nightly 58.0a1 from October 21, 2017 https://archive.mozilla.org/pub/thunderbird/nightly/2017/10/2017-10-21-03-02-01-comm-central/
Tested it and last good is https://archive.mozilla.org/pub/thunderbird/nightly/2017/10/2017-10-22-06-24-16-comm-central/ first bad is https://archive.mozilla.org/pub/thunderbird/nightly/2017/10/2017-10-24-03-02-01-comm-central/ 2017-10-23 is empty. So regression must be between 20171022062416 https://hg.mozilla.org/comm-central/rev/9760a85ceffe37a3c77225e5a9242da98d9ae6b9 https://hg.mozilla.org/mozilla-central/rev/69e24c678a28dc46a4c1bda3ff04b2f6106ff71a and 20171024030201 https://hg.mozilla.org/comm-central/rev/ad44eb6ab134472e1399e1f4cd6de6e0f94dd478 https://hg.mozilla.org/mozilla-central/rev/a80d568a417ea8410cd2d874c1e0267fb92888fe
(In reply to Richard Marti (:Paenglab) from comment #21) > Tested it and last good is > https://archive.mozilla.org/pub/thunderbird/nightly/2017/10/2017-10-22-06-24- > 16-comm-central/ > first bad is > https://archive.mozilla.org/pub/thunderbird/nightly/2017/10/2017-10-24-03-02- > 01-comm-central/ > I'm confirming. Don't remember why I couldn't find the download links for those two versions ...
From bug 1482157 comment 4 this seems to be because the dialog is somehow attached to the last toolbar. With attachments this will be the attachment toolbar on bottom. I could convert this to a normal hbox. But then we still have the message header toolbar which we can't convert without loosing our functionality. Markus, please can you explain how this dialogs are attached to the toolbars (how is the logic to attach the dialog) and what we could do to fix this here?
Summary: Intermittent modal dialog open at wrong location, sometimes unusable → Sometimes modal dialog open at wrong location, sometimes unusable
Summary: Sometimes modal dialog open at wrong location, sometimes unusable → Sometimes modal dialog open at wrong location, sometimes unusable (Mac)
You need to log in before you can comment on or make changes to this bug.