If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Lightning hides Thunderbird master password prompt + multiple password prompts

Assigned to


6 years ago
2 months ago


(Reporter: Cyril, Assigned: Fallen)


(Depends on: 2 bugs, Blocks: 2 bugs)

Lightning 1.3
Dependency tree / graph



(1 attachment, 1 obsolete attachment)



6 years ago
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv: Gecko/20110803 Firefox/3.6.20 (.NET CLR 3.5.30729)
Build ID: 20110803131630

Steps to reproduce:

This bug had different forms from Thunderbird 3.1.10 / Lightning 1.0b2 Linux and WinXP to Thunderbird 6.0 / Lightning 1.0b5 Linux and Win7.
Multi-password prompt have been partially fixed https://bugzilla.mozilla.org/show_bug.cgi?id=349641 in normal usage condition, but password prompt is still hidden by main window, and multiple password prompts still occurs if master password haven't been entered quickly.

Steps to reproduce several aspects of the bug:
* TB 6.0 install (from .bzip under Linux Ubuntu 11.04 x86 32 bits)
* one e-mail imap account creation (or pop) with authentication + remember
* set master password
* Addon Lightning 1.0b5 install + 1st TB restart
* 2 network CalDAV calendar creation, with authentication + remember (in my case, the 2 calendars are on the same DAViCal LAN Server, and can be accessed with the same authentication, but this bug have been reported with different configurations)
* 2nd TB restart
* 3rd TB restart + long wait (> 10 minutes, default IMAP refresh, but can be set to 1 minute to speed up tests: Edit - Account Settings - Server Settings - Check for new message every 1 minutes)
* switch Calendars Off (right click on calendar + properties + uncheck "switch this calendar on", for each calendar) and 4th TB restart
* switch each calendars on + refresh every minute
* if modified set email check for new message back to 10 minutes
* 5th TB restart + long wait (2min 30sec)
* switch each calendar off
* set email check for new message to 1 minute
* 6th TB restart + long wait (2min 30sec)

Actual results:

* 1st TB restart (1 imap + 0 calendar): main TB window displayed + 1 master password prompt on top of screen, only one TB windows in task bar  --> OK
* 2nd TB restart (1 imap + 2 network calendars): 1 master password prompt immediately hidden by main TB window, 2  TB windows in task bar --> inbox is not refreshed and calendars are empty --> need to click on task bar to bring master password prompt on top, then type it, then ok.
* 3rd TB restart (same as 2nd TB restart, but don't enter master password, just wait) --> 10 minutes later, a new master password prompt appears in front of main TB window (for IMAP refresh). Enter master password in this new window. Click on background master password window and enter twice.
* 2 calendar passwords are successively prompted, even if remember is asked.
* 4th TB restart (same as 1st TB restart) --> main TB window displayed + 1 master password prompt on top of screen --> OK
* 5th TB restart (same as 3rd TB restart, don't enter master password, just wait) --> 1min later, no new master prompt, wait 1min 30sec more, Click on background master password window and enter it. --> 4 successive calendar password prompts are asked to you, even if you check remember, and even if you have entered a correct master password.
* 6th TB restart (same as 1st restart: main TB window displayed + 1 master password prompt on top of screen, only one TB windows in task bar, ok but don't enter master password, just wait) --> 1 minute later, a 2nd Master password prompt rises (seems a pure Thunderbird bug), wait 2 more minutes, no other Master password prompt. --> enter master password in top window, cancel (or enter) the other master password window --> all finally ok.

Expected results:

* no specific Master password prompt window in task bar, Master password prompt is always asked from main TB window what ever password firstly required by TB or Lightning.
* no other Master password prompt, even if master password is not entered quickly (< IMAP Refresh or < calendar refresh) in first prompt.
* no other calendar specific password prompt, even if master password is not entered quickly (<calendar Refresh) in first prompt.

This bug might be linked with https://bugzilla.mozilla.org/show_bug.cgi?id=612591

This bug also happens with only one network calendar, but please, consider testing any fix with 2 network calendars set to prevent any regression with multiple master password prompt in normal conditions!

Enjoy! :-]

Comment 1

6 years ago
For such a small, this one sure is annoying. Been having this problem for ages and now with TB 6.01 + Lightning 1.0b5

Comment 2

6 years ago
Can confirm the problem of multiple master password requests when starting thunderbird with lightning addon installed using thunderbird 7.0.1 on linux. 

My personal workaround is to use an addon (Startupmaster) that only asks once for the master  password but such a workaround should of course not be needed.  


Comment 3

6 years ago
This affects me as well.   I have multiple calendars to load using lightening, and I'm prompted with the master password for each one, as well as one for the login to the IMAP server.  Canceling the input breaks the login.

I'm also using the Startupmaster addon as a workaround.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15

Comment 4

6 years ago
@Calendar team: I am confirming this behavior in comm-central, please mark as "NEW" and triage (and update version).

With the current Thunderbird and Lightning nightlies for 64-bit Linux, I can reproduce all of the behavior described in comment 1, both with and without FIPS mode, except that the master password prompt always appears in front of the Thunderbird window.

Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111126 Lightning/1.3a1 Thunderbird/11.0a1


6 years ago
Ever confirmed: true
Version: Lightning 1.0b5 → Lightning 1.3
Blocks: 612591

Comment 5

6 years ago
I've been seeing this for a long time now on linux with Gnome 3.  An additional aggravation is that frequently one of the password dialogs appears under the main thunderbird window.  (I think it might be getting displayed before the main window, so the window manager can't put it in the right place?)  Sometimes there are two separate master password dialogs and sometimes one appears as a regular framed window and the other appears attached to its title like other Gnome dialogs.

I've also encountered a sporadic problem where several password and reminder dialogs appear when thunderbird starts, and one of them is modal, but it's hidden under another dialog.  You can't type in any of the others or dismiss them until you figure out which one is modal and handle it.
Blocks: 570421

Comment 6

5 years ago
And here we are at the summer of 2012, and STILL this 7 year old bug is alive!
StartupMaster is a solution, but a bloody stupid one!
If we can fix this with an AddOn, why not fix the problem instead?
Clearly there is some concensus to simply ignore this bug, but why??

Comment 7

5 years ago
I had this problem when using Lightning with Google Calendar. However, the problem was solved by NOT using the "Provider for Google Calendar" plugin. Instead, use Caldav as recommended by Google. (http://support.google.com/calendar/bin/answer.py?hl=en&answer=99358#sunbird)

Comment 8

5 years ago
Even StartupMaster isn't fixing the problem for me.  Fedora 17 / Thunderbird 13.0.1 / Lightning 1.5

Comment 9

5 years ago
I think I just fixed my problem.  The problem is that I'm subscribed to a bunch of caldav calendars using urls which include my username, e.g. https://noahf@foo.bar.com/caldav/... and even though I have a saved password entry for user noahf on https://foo.bar.com, lightning isn't using it without confirmation because the urls don't match.

I used the SavedPasswords editing extension to modify the site url to https://noahf@foo.bar.com and now everything's working perfectly.

So, why is the password manager stripping usernames out of the site url?  I realize it's partly redundant, but it produces a profoundly annoying result because I have to confirm every login.

Comment 10

5 years ago
Agreed with comment #7.

While one calendar was loading correctly bizarrely one was always disabled when I started thunderbird. Using caldav seemed to be quicker, removed the need for the google provider and actually worked ;-)

Comment 11

5 years ago
Note that original bug report was with CalDav protocol, TB + Lightning addon only, but a lot of calendars.

Comment 12

5 years ago
In my case, each additional MP request depends on one more calendar used through "Provider for Google Calendar" plugin.

Comment 13

5 years ago
I also reject the thought of using an extension for the most sensible part of my Thunderbird setup. That's just not an option.

But throwing away the Google Calendar provider and using CalDav instead solved the problem for me, too.

This is Thunderbird 17.0.5 with Lightning 1.9.1 under Win 7 64bit.

Comment 14

5 years ago
I seem to have this issue as well on both Linux(Fedora 64) and Windows 7(64).

Comment 15

5 years ago
(In reply to nemo from comment #13)
> But throwing away the Google Calendar provider and using CalDav instead
> solved the problem for me, too.
> This is Thunderbird 17.0.5 with Lightning 1.9.1 under Win 7 64bit.

Same configuration on Linux, but using CalDAV for Google calendar *still* causes a second password popup :-(


4 years ago
Duplicate of this bug: 680053


4 years ago
Duplicate of this bug: 810408


4 years ago
Depends on: 643265

Comment 18

4 years ago
Same for me.
- Win7 64
- Thunderbird 24.2.0

I think the problem is also with Lightning and shared calenders e.g. google or exchange.
I used Exchange EWS Provider Plugin to provide the exchange function.

With Lightning, Google and exchange calender i got 5 logins :-(
I've can confirm that I've got the same problem here even with CalDav.
Ok if you remove the Google Provider for Google Agenda and use CalDAV urls like that:


It seams to work.

Comment 21

4 years ago
This is not completely right.
But it brings me to the right way.

I uninstalled also the Google Provider Addon and created a new calender like that:

<calid> = Your calender id e.g. mycalendar@domain.de

After this everything works fine.

You can read about this at following site.

Another useful ressource but german only.

Comment 22

3 years ago
(In reply to Niels Tiedt from comment #21)

Thank you Niels so much, solved the issue for me right away!

Comment 23

3 years ago
(In reply to Niels Tiedt from comment #21)
> After this everything works fine.

Can confirm, thank you so f***ing much, this has bugged me for years (litterally)!

Comment 24

10 months ago
Created attachment 8813918 [details] [diff] [review]
Fix - v1

Requires bug 1176399, but should fix this case.
Assignee: nobody → philipp
Attachment #8813918 - Flags: review?(makemyday)


10 months ago
Depends on: 1176399

Comment 25

8 months ago
I guess this patch will change also when you pick up the r- patch from bug 1176399 - or is it good for review still?

Comment 26

8 months ago
It is still good to review, I just needed to change one line in bug 1176399. If you want to test there is a try run at


Comment 27

8 months ago
Comment on attachment 8813918 [details] [diff] [review]
Fix - v1

Review of attachment 8813918 [details] [diff] [review]:

Sorry it took some time to get to this review. Please check the var naming as mentioned below. r+ with that checked.

::: calendar/providers/caldav/calDavCalendar.js
@@ +1554,5 @@
>      //
>      // Helper functions
>      //
> +    oauthConnect: function(authSuccess, authFailure, aRefresh=false) {

Can you append Cb to the first two arguments here?

@@ +1562,5 @@
> +                self.oauth.connect(() => {
> +                    authSuccess();
> +                    callback.onAuthResult(true);
> +                }, () => {
> +                    authFailed();

should that be authFailure resp. authFailureCb instead?

@@ +1568,5 @@
> +                }, true, aRefresh);
> +            },
> +
> +            onPromptAuthAvailable: authSuccess,
> +            onPromptCanceled: authFailed,

same here.
Attachment #8813918 - Flags: review?(makemyday) → review+

Comment 28

7 months ago
Created attachment 8841219 [details] [diff] [review]
Fix - v2

Patch with nits fixed, thanks for catching those!
Attachment #8813918 - Attachment is obsolete: true
Attachment #8841219 - Flags: review+

Comment 29

6 months ago
What's happening here? This looks like it's ready for landing. What are we waiting for? Or does this depend on bug 1176399?
Flags: needinfo?(philipp)

Comment 30

6 months ago
Yes, waiting on bug 1176399
Flags: needinfo?(philipp)

Comment 31

6 months ago
bug 1176399 is now checkin-needed, so this one should be ready to go together with it.
Keywords: checkin-needed

Comment 32

6 months ago
Last Resolved: 6 months ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 5.7

Comment 33

5 months ago
Comment on attachment 8841219 [details] [diff] [review]
Fix - v2

Jörg, if you need a calendar uplift just go ahead and request it via the flags. Once it is approved (as is now), you can do the push at your convenience.
Attachment #8841219 - Flags: approval-calendar-beta+
Attachment #8841219 - Flags: approval-calendar-aurora+

Comment 34

5 months ago
Aurora (TB 54, Calendar 5.6):

Beta (TB 53, Calendar 5.5):

(In reply to Philipp Kewisch [:Fallen] from comment #33)
> Jörg, if you need a calendar uplift just go ahead and request it via the
> flags. Once it is approved (as is now), you can do the push at your
> convenience.
The developer or code manager requests the uplift, not the sheriff, which I am in this case since I'm not managing Calendar.
Target Milestone: 5.7 → 5.5


5 months ago
Depends on: 1359967


5 months ago
Attachment #8841219 - Flags: approval-calendar-esr?(philipp)


5 months ago
Attachment #8841219 - Flags: approval-calendar-esr?(philipp) → approval-calendar-esr+

Comment 35

4 months ago
TB 52 ESR, Calendar 5.4.x:
Target Milestone: 5.5 → 5.4.2

Comment 36

3 months ago
TB 52 ESR - Backout:
Target Milestone: 5.4.2 → 5.5

Comment 37

2 months ago
Beta (TB 55, Calendar 5.7) backout:
Target Milestone: 5.5 → 5.8

Comment 38

2 months ago
Backout from trunk:

Sorry, I had to back this out since the next merge date is coming and I can't continue to back it out from all the betas we ship.
Resolution: FIXED → ---
Target Milestone: 5.8 → ---
You need to log in before you can comment on or make changes to this bug.