Closed Bug 1612456 Opened 4 years ago Closed 2 years ago

About & Preferences windows don't appear (on Mac) when there's a master password and security.prompt_for_master_password_on_startup is set to true

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: calum.mackay, Assigned: KaiE)

References

(Regression)

Details

(Keywords: leave-open, regression)

Attachments

(1 file)

1612456-workaround-v1.patch
1.20 KB, patch
mkmelin
: review+
Details | Diff | Splinter Review

The "About" box no longer appears, when selected from main menu.

OK in Daily 0127, problem appeared in Daily 0128.

MacOS 10.14.6

It's a minor pain: current version can be got from Help -> Troubleshooting

update on demand is lost; need to wait for update prompt to appear

forgot to add: nothing at all in Console when selecting About from menu.

sorry, belatedly noticed that Preferences doesn't appear either.

Severity: normal → critical
Summary: About box doesn't appear → About & Preferences windows don't appear
Keywords: regression

Khushil, do you see this?

It's working on TB 74.0a1 on MacOS 10.14.2. (Last Patch from Wed 29th Jan)
What is Daily 0128?

I'd say 28. January. On my Mac it still works. I saw also reports of this issue with TB 68.

(In reply to Richard Marti (:Paenglab) from comment #5)

I'd say 28. January. On my Mac it still works. I saw also reports of this issue with TB 68.

I am using 10.13 SDK for development. Do you think it can be related to 10.14 SDKs?

I don't think it's a SDK issue as the official Daily works for me too. And they use if I'm right a older SDK.

That's odd. I'm using the official Daily builds too.

I can reliably reproduce it with every Daily from 0128 on, including today's 0205.

Equally reliably, going back to Daily 0127 restores normal behaviour.

This is on MacOS 10.14.6

[No doubt it's a coincidence, but the other noticeable UI change in Daily 0128 (my first "bad" build) is that the master password prompt comes up alone, on startup, and the main windows do not appear until the pw has been entered. With 0127 and before (for years), the main windows (I use two) come up first, then the master pw box comes up later. Probably a coincidence, but it caught my eye in that first "bad" (for me) build]

Anything I can do, to try and narrow this down?

Good catch Calum, when I enable the master password I can confirm your issue.

Khushil, can you look at why the main menu doesn't work after the master password dialog is used? If I remember correctly is Kai on Linux. But I n-i him anyway.

Flags: needinfo?(kaie)
Regressed by: 1610390

thanks Richard; glad I mentioned it :)

Yes, I also confirm. After setting up the master password, it doesn't work.

confirmed; adding this resolves this problem in Daily 0205

$ grep master user.js
user_pref("security.prompt_for_master_password_on_startup", false);

I should add, despite the regression, I'm delighted with Kai's master password prompt on startup; multiple prompts have been a pain for me for years. thanks Kai :)

Summary: About & Preferences windows don't appear → About & Preferences windows don't appear (on Mac)

I just tried Nightly 2020-02-05 on Linux.
I can use menu "help/about daily" successfully.
Enabling the master password doesn't have an effect for me, I can open the about dialog and preferences window with and without master password on Linux.

I can try on Mac.

I can reproduce the issue on MacOS. And it isn't possible to quit Daily using the menu command.

So apparently bringing up the master password prompt confuses the windowing system on Mac. We might need to do it at a different point of time. This needs investigation.

Anyway, we shouldn't break users of nightly. I suggest we disable the pref until we have a chance to identify the cause and a better fix.

Flags: needinfo?(kaie)
Assignee: nobody → kaie
Attachment #9124629 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9124629 [details] [diff] [review]
1612456-workaround-v1.patch

Review of attachment 9124629 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/app/profile/all-thunderbird.js
@@ +362,5 @@
>  pref("security.aboutcertificate.enabled", false);
>  
>  // Prompt for the master password prior to opening application windows,
>  // to avoid the race that triggers multiple prompts (see bug 177175).
> +pref("security.prompt_for_master_password_on_startup", false);

You could alternatively disable it for mac only with a #ifdef XP_MACOSX
(and reference this bug)
Attachment #9124629 - Flags: review?(mkmelin+mozilla) → review+
Status: NEW → ASSIGNED
Keywords: leave-open
Summary: About & Preferences windows don't appear (on Mac) → About & Preferences windows don't appear (on Mac) when there's a master password and security.prompt_for_master_password_on_startup is set to true

Ok. I've now tested Windows, which seems to work. So your suggestion to disable mac only is good.

I've noticed a different issue, without MP set and nightly, I occasionally get a mail server login failure on startup. Cannot reproduce reliably. I don't yet know if this is related to the new NSS startup code.

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/230eadb7ddd6
Disable master password startup pref on MacOS to fix a regression. r=mkmelin DONTBUILD

Khushil, can you confirm this is still an issue on mac?

Flags: needinfo?(khushil324)

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

Khushil, can you confirm this is still an issue on mac?

It is working on Daily 79.0a1. So the issue is solved.

Flags: needinfo?(khushil324)

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/230eadb7ddd6
Disable master password startup pref on MacOS to fix a regression. r=mkmelin
DONTBUILD

The issue is reproducible without this patch.

I recently noticed that the master password prompt appeared at startup, again, despite the pref security.prompt_for_master_password_on_startup now defaulting to false; the problem reported here no longer occurs in that state, i.e. with the pref default of false, even though the master password is now prompted for at startup, which seems odd.

However, if I manually set that pref true, in user.js, the problem reported here returns; current Daily 20200609.

(In reply to Calum Mackay from comment #23)

I recently noticed that the master password prompt appeared at startup, again, despite the pref security.prompt_for_master_password_on_startup now defaulting to false; the problem reported here no longer occurs in that state, i.e. with the pref default of false, even though the master password is now prompted for at startup, which seems odd.

However, if I manually set that pref true, in user.js, the problem reported here returns; current Daily 20200609.

Yes. I am also observing the same.

Is this issue still relevant after Kai's most recent patch(es)? Should be available on the following:

I don't think I have seen the issue before, but also working for me with 78.3.0; macos 10.14.6; MP on;

(In reply to Calum Mackay from comment #23)

I recently noticed that the master password prompt appeared at startup, again, despite the pref security.prompt_for_master_password_on_startup now defaulting to false; the problem reported here no longer occurs in that state, i.e. with the pref default of false, even though the master password is now prompted for at startup, which seems odd.

However, if I manually set that pref true, in user.js, the problem reported here returns; current Daily 20200609.

I am able to reproduce it with these steps.

Wayne, yes the issue still applies.

Bug 1610390 implemented a fix for Windows and Linux.

The fix doesn't work on macOS. That's why we kept the pref at disabled, which means "don't use the code from bug 1610390 on macOS".

This means -> no solution for macOS yet.

To report some progress, I've recently tried to look into it. A hidden window is created on macOS, and in order to allow the prompt to work, we need to bring up the hidden window earlier. But even with that, it doesn't completely work on macOS, because a second prompt is brought up (while spinning the even loop while prompting for the password). So a more sophisticated fix will be necessary for macOS.

[Edit, clarify no solution for "macOS" yet]

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

Is this issue still relevant after Kai's most recent patch(es)?

Yes

Should be available on the following:

No. Those other recent fixes are irrelevant for this issue, as I explain above in comment 28. That recent work fixed another scenario which made it even worse (on all platforms).

thanks Kai!

Not sure if bug 1668470 is related. These menu items not working on Mac if app window closed (not quit).

Blocks: 1695142
See Also: → 530608

Adding Markus to this bug, who I just learned is an expert for the macOS windowing system. Maybe you could eventually help us to better understand what might be causing this window misbehavior.

Does this still reproduce?

Flags: needinfo?(calum.mackay)

I'm delighted to report that it no longer reproduces :)

i.e. setting:

user_pref("security.prompt_for_master_password_on_startup", true);

no longer breaks About or Prefs.

And enabling that pref does fix the multiple prompt issue, too, which is marvellous.

thanks!

Flags: needinfo?(calum.mackay)

Thanks for the update

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME

Calum, on which macOS version did you test?

I confirm it also works for me with TB 102 and this pref on macOS 12.4

The last time I had tried it was on macOS 11.x - I would like to know if this is also fixed with TB 102 on macOS 11.x - can we find someone who is able to test that?

Good news.

I got access to an older mac stuck at with macOS 10.12.x.
With Thunderbird 102 on macOS 10.x, this bug is fixed, too!

This makes it very likely that it works on macOS 11, too, and the fix was indeed somewhere in the new Thunderbird release.

I suggest that we enable the startup pref for macOS in an update to 102.x, I'll file a separate bug for that.

Blocks: 1778725

sorry Kai!

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

Calum, on which macOS version did you test?

I forgot to add that: 104.0a1 (2022-07-07) (64-bit); MacOS 12.4

Depends on: 1778922
No longer depends on: 1778922
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: