Open Bug 275547 Opened 20 years ago Updated 8 months ago

Cancel Primary / Master Password entry doesn't cancel without multiple tries

Categories

(Thunderbird :: Security, defect)

Product:
Thunderbird
Component:
Security
Version:
38 Branch
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

People

(Reporter: Brad+Mozilla_old, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

On startup (for example, when I startup thunderbird by accident) I need to hit
the cancel button many times in order to get to a place where I can shut it down .

Steps to reproduce:

* Start thunderbird  (say, by accident.  Now I just want to stop it)
* Popup "Please Enter the Master Password..." appears.
* Hit Cancel.  Popup reappears.
* Hit Cancel again.  Popup reappears.
* Hit Cancel again.  Popup for IMAP account password appears.
* Hit Cancel again.  Ah, now it is canceled.
* Hit the window bar close button.  Now, finally, it quits.

Expected behavior:
* Hitting cancel should block immediate re-request.  I realize that the password
store is being queried for different reasons, but at the user interface, this is
hidden, and it feels like the system just "didn't hear me".
* Or - enable the window bar close button while the modal popup is up, so I can
just exit without having to click multiple times.

I'm not wedded to any of these.  I just thought I'd mention it felt awkward
(and this stands out in an otherwise excellent release).

- brad
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

In my installation of thunderbird on Windows NT (20041206), which has 1 IMAP and
3 POP accounts:  I launch thunderbird, and I am asked for my master password.  I
hit cancel because I just want to shut down.  I am then asked for my password 20
times (and I hit cancel 20 times) before the modal dialog boxes go away and I am
presented with the main application window from which I can quit.

I still maintain that after the first time I hit cancel, thunderbird should
"cancel". 

But perhaps I'm the only who cares.
No, I came to report this same bug. I have to push cancel 4 times for each POP account. For me that means I have to push cancel 12 times in order to open Thunderbird without entering a password.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 327015 has been marked as a duplicate of this bug. ***
QA Contact: front-end
This exists (more or less) in firefox as well - resuming the browser from stored session to pages that require logins causes repeated invocation of the master password dialog.  One should clearly be enough, and even if you wanted to pick and choose which were remembered, there isn't a mechanism to do that under normal circumstances - it's only relevant for simultaneous loading (practically, that means only at start up).

It's part of the same design flaw that makes you have to enter the password multiple times for each simultaneous request.  You have to cancel repeatedly or enter the password repeatedly.
When the master password dialog is canceled during an _automatic_ check for new mail, this means that the user doesn't want to check for new mail at this moment. So Thunderbird should just go offline instead of asking for every single account password. There could be some visual hint that it went offline in addition to the offline icon, but please don't make it another modal alertbox ;)

When the master password dialog is canceled during a _manual_ check for new mail, Tb should just stop checking mail, but not change its online status.
This issue should be resolved when TB is using the new password manager.
Assignee: mscott → dveditz
Component: Mail Window Front End → Security
Depends on: 239131
QA Contact: front-end → thunderbird
Any update to this? Jack hit the nail on the head, but his comment was posted over a year ago! I have been plagued with multiple master passwords on start up (with previous session/tabs enabled on restart) for as long as I can remember in Firefox (even pre-version 2). 

Our web software utilizes user authentication, so if I have multiple portals open in tabs when I close the software, reopening yields 2 or more "master password" prompts, PLUS the user authentications for each portal (although, at least those are saved). This gets excessively annoying when I'm closing the software with 5 tabs... 
I am experiencing a variation of this problem on FF 3.0.1 (kubuntu hardy).
Often when I start FF, the first thing I do is open a bookmarks subfolder and click open all in tabs. Since all four of the tabs that get opened in this case are to web pages that require passwords, I get four master security prompt windows.  Once I enter the password for the first one (which ever one ends up on top), I still have to enter the same password 3 more times.  It would be nice if FF noticed that it had the answer and closed these other dialogs itself.  I did not see this problem in FF 2.x.

This only occurs if I have not already entered the password by doing something else before opening the multiple tabs.
(In reply to comment #10)
> I am experiencing a variation of this problem on FF 3.0.1 (kubuntu hardy).

Ditto here under OS/2 w/FF 3.0. I know that there was a SeaMonkey bug filed under a similar description, but I have been unable to locate it as yet. It was resolved on trunk (IIRC), so this must be a regression (or may only impact FF - the SuiteRunner builds of SM for OS/2 are currently stalled, AFAIK, so I have nothing contemporary against which to compare behavior).

Anyway, this one is rather annoying...



Ok the new password manager as landed in Thunderbird. reporter and other CCed can someone try a nightly or the to be b2 and update the bugs telling us if it's fixed ?
Even with TB 3.0.4 release or latest beta I still can't cancel the master password dialog as it immediately reappears (once per configured mail/news account).  It is nearly impossible to close TB once the master password prompt appears unless you hit the Esc key rapidly and happen to be able to hit "X" or Alt-F4 to close TB before it prompts you again.
Just switched to Thunderbird 3.1 beta 2 (candidate build 2), and this still happens, and it's still really annoying.
Same here (3.0.4, Windows), but instead of multiple tries, master password never stops asking. As it is a dal dialog, it is really difficult to close Thunderbird.
does this happen with thunderbird started in safe mode?
(In reply to comment #16)
> does this happen with thunderbird started in safe mode?

At least on 3.1.9, yes.
might 978715 be a duplicate?

and 643265 related?
can replicate it with the latest beta on OS X
OS: Windows XP → All
Version: unspecified → 38
This exactly the same as multiple master password request. 
Several password entry boxes stacked one under the other. 
Entering password once or canceling entry just closes top 
password box.
Depends on: 1176399
Now using Google OAUTH authentication adds additional password dialogs.  Entering your password once and then clicking "OK" on the numerous other dialogs works.  This is a major blow to the maturity/credibility of the product, given that the issue was first reported 13 years ago and persists to this day.
(In reply to Thomas Brown from comment #21)
> Now using Google OAUTH authentication adds additional password dialogs. 

The oauth issue is different report, bug 1176399, and is being worked on.

For people reporting the issue prior to July 2015, afaict there had been at some point a resolution. But then it broke again.  That too will hopefully be resolved in the coming months.

In general the workaround is to disable checking for new mail on startup in acount settings
Still an issue on latest TB 60.0 build 20180731173940 (32-bit).  Multiple master password prompts overlay each other for each account (5 in my case--4 using OAUTH, 1 using traditional SSL/TLS).  You can enter the master password once, and then simply click "OK" on the other 4 windows.  Trying to click cancel to exit the app yields the same behavior.
Assignee: dveditz → nobody

I have the same issue in Thunderbird 78.1.1

I am using several calendars in Lightning. And I am getting a "master password" Request for every single calendar, they open up right at start of Thunderbird, behind each other. If I enter my password in the first requester I can just click "OK" on the other ~10 requesters one by one and everything will work.

VERY annoying.

Oliver, please post your results with 78.3.0 which will be available later this week

Flags: needinfo?(vaross)
Summary: Cancel Master Password entry doesn't cancel without multiple tries → Cancel Primary / Master Password entry doesn't cancel without multiple tries

Still occurs.
Environment: Thunderbird 91.5.1, Linux

  1. Start Thunderbird
  2. Click Cancel when asked "Please enter your Primary Password"
  3. Same prompt is displayed multiple times (i.e., 20 accounts = 20 dialogs = 20 click Cancel)

Version: 91.5.1, Windows
Passoword Pop-Up:

If I click Cancel often enough Thunderbird will just start without any further input. The pop up will randomly open again, but I can just cancel it again and read all my E-Mails on all my accounts. Thunderbird does not syncronize then though.

91.8.1 (64-bit), Arch Linux

Still happening. I have Thunderbird in autostart because otherwise I forget to check my emails, but it should be enough to hit "cancel" once to close Thunderbird. There is absolutely no reason to repeat asking for a password when the user has pressed cancel. It is very annoying and has literally been a problem for over a decade. Why is there not even an about:config setting for this? There is an "abuse" setting, but it only seems to apply to email account password dialogues. It seems to me that fixing this would merely involve changing literally a single variable in the code. How has this been an issue for 17 years?

It seems to me that this bug will be fixed when bug 1778725 would be.

Severity: minor → S3

(In reply to Nicolas Mandil (:NicolasWeb) from comment #29)

It seems to me that this bug will be fixed when bug 1778725 would be.

sonofevil, ad.astra, prusseltechgroup,

do you agree this is gone?

Flags: needinfo?(vaross)
Flags: needinfo?(prusselltechgroup)
Flags: needinfo?(debilerpc)
Flags: needinfo?(ad.astra)

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

(In reply to Nicolas Mandil (:NicolasWeb) from comment #29)

It seems to me that this bug will be fixed when bug 1778725 would be.

sonofevil, ad.astra, prusseltechgroup,

do you agree this is gone?

102.14.0, Windows

Bug still persists. I press cancel and Thunderbird launches regardless. Password window pops up again, and if I press cancel enough times goes away. I can then look at all E-Mails. This is still very concerning.

Flags: needinfo?(ad.astra)

I'm on 115.1.0 (64-bit) for Linux.

When launching, password prompt appears. Closing it opens the main Thunderbird window and a new password prompt. Closing the second prompt makes it go away permanently.

Flags: needinfo?(debilerpc)

Same behaviour as described by sonofevil above on 115.1.1 for macOS 13.5. Was happening on 102 as well.

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