Closed Bug 560793 Opened 15 years ago Closed 13 years ago

Multiple (master) password prompts on startup when using news authentication - Hook up NNTP to msgAsyncPrompt service

Categories

(MailNews Core :: Networking: NNTP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 13.0

People

(Reporter: standard8, Assigned: jcranmer)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #560792 +++ Spinning out the separate work from bug 338549. We need to hook up NNTP to the msgAsyncPrompt service so that the prompts will occur in serial fashion. I believe we'd hit this case very rarely, but we should still do it anyway at some stage.
Blocks: 419354
We hit this case, if in folderpane a newsgroup was selected, when Thunderbird was closed. (Re-)opening Thunderbird than leads to multiple masterpassword dialogs.
Summary: Hook up NNTP to msgAsyncPrompt service and make its password prompts serial again → Multiple (master) password prompts on startup when using news authentication - Hook up NNTP to msgAsyncPrompt service
No longer blocks: 419354
As said on my now duped bug, this is a regression. Adding keyword.
Keywords: regression
Every time I start Thunderbird I get the master password dialog twice. Once for mail and once for RSS feeds. (My news accounts don't load automatically at startup.) When I turn off "Check for new articles at startup" for the RSS feeds, I get the master password dialog only once. But I want to check these feeds only once a day, not every xx minutes, so I prefer to keep it the way I have it. I found this bug through bug 570935, which more resembles my problem, but has been marked as a duplicate of this bug. It worked better in TB 3.0 (as mentioned in comment 4).
I have this problem too. 2 requests in a row for master password. I have a master password set. Additionally, I automatically download my gmail upon TB startup. However, none of my newsgroup subscriptions are set to automatically download new messages upon startup (even though 1 of them requires a password each time I log in - I never get asked a 3rd time when I click on the name of that usenet service to download it's new messages).
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.14) Gecko/20100930 SeaMonkey/2.0.9 I don't know if it is this bug or bug #560792. I get a prompt for my master password every time I launch SeaMonkey if the preference variable signon.startup.prompt has the default value of "true". Thus, this is not a rare occurrence. I launch SeaMonkey only for the browser. I don't use SeaMonkey's Mail-News capability and never open it.
(In reply to comment #9) > I launch SeaMonkey only for the browser. I don't use SeaMonkey's Mail-News > capability and never open it. If you don't use mail-news and never set it up, then your issue is not likely to be a mailnews bug.
I'm using Thunderbird 3.1.5 and this happens at every log in. It's annoying because it happens right at startup, before it's possible to preempt the problem by using Tools -> Options -> Security -> Saved Passwords to enter the password manually first.
Same problem here! TB 3.1.6, new profile, Email and news setup. The only difference is that I have to enter the password three times, not only two.
It seems it is not necessary to enter the password on all prompts. After entering the password at the first prompt, the other dialog(s) can just be closed by pressing <Enter>.
If I do not enter all password "rapidly", the system hangs on Linux. This render this bug even more annoying.
7 months after, it is still not fixed and still freezes the application if password are not entered rapidly enough. If only kmail was available on windows I would have moved away!
I found a workaround: mail.server.default.login_at_startup -> true mail.server.server3.login_at_startup -> false mail.server.server4.login_at_startup -> false mail.startup.enabledMailCheckOnce -> true (am not sure that last one matters)
I have this problem too. The problem is not related with NNTP, it's just that TB opens as many prompts as passwords it needs at startup. I have a few mail accounts and lightning calendars and it opens as much as needed. It's like if TB tries to ask for the passwords concurrently instead of just a one and then lock waiting for the master password. If you have an account that doesn't read mail automatically, when you read it, you don't have the problem, because when TB needs its password, you have previously (at startup) entered the master password. I have the problem with TB 3.1.7 in linux (ubuntu package), but I'm getting since previous versions.
Nearly a year and a half and no progress. I still need to enter 3 passwd each time in start thunderbird. This is getting on my nerfs.
The good "news" is, it isn't really necessary to enter the master password multiple times (same for Firefox). Enter the master password once and press OK for all other prompts without entering anything.
Assignee: nobody → Pidgeot18
Status: NEW → ASSIGNED
Depends on: 201750
Attached patch Introduce nsNNTPProtocol to the async prompter (obsolete) (deleted) — Splinter Review
This patch also has a bit of cleanup (s/NEWS_FINISHED/NNTP_SUSPENDED/ to correct what the state actually means), and a lot more documentation (particularly about NNTP_SUSPENDED)--if you don't feel comfortable reviewing this, switch it to someone else.
Attachment #582417 - Flags: review?(mbanner)
Comment on attachment 582417 [details] [diff] [review] Introduce nsNNTPProtocol to the async prompter Review of attachment 582417 [details] [diff] [review]: ----------------------------------------------------------------- ::: mailnews/news/src/nsNNTPProtocol.cpp @@ +2384,5 @@ > nsCOMPtr<nsIMsgMailNewsUrl> mailnewsurl = do_QueryInterface(m_runningURL); > if (!m_msgWindow && mailnewsurl) > mailnewsurl->GetMsgWindow(getter_AddRefs(m_msgWindow)); > bool validCredentials = false; > + rv = m_newsFolder->GetAuthenticationCredentials(m_msgWindow, false, false, You can't do this here, it must be inside the prompter call. The reason being is that just accessing the login manager may cause the master password prompt to appear, and you need to be in async mode by that time. I think with other protocols, we've generally checked the result value from GetPassword (stored in nsMsgIncomingServer iirc) to see if it is empty or not, if it is, then we've gone into the auth check. You could probably do similar here, but maybe with the username. As this change may reflect on the other patch, I'll wait until you've taken a look before testing this out.
Attachment #582417 - Flags: review?(mbanner) → review-
Reviewing the code manually seems to indicate that I was mentally overcompensating for bug 437930. If I make the async bit only a mayPrompt and not a mustPrompt, I don't need the mustNotPrompt here. Even though I could probably get by with only checking GetUsername, if I add support for having multiple Usenet accounts with the same server but different username, that would lead to a false positive. Patch pending while I think about bug 201750 some more.
Attached patch Updated patch (deleted) — Splinter Review
This should remove the password prompter issue, although I suspect I need some more work later on to finally fix bug 437930...
Attachment #582417 - Attachment is obsolete: true
Attachment #591980 - Flags: review?(mbanner)
Comment on attachment 591980 [details] [diff] [review] Updated patch Unfortunately, test_uriParser.js is always failing with: ###!!! ASSERTION: nsNSSComponent relies on profile manager to wait for synchronous shutdown of all network activity: 'mIsNetworkDown', file /Users/moztest/comm/main/src/mozilla/security/manager/ssl/src/nsNSSComponent.cpp, line 2590 ###!!! ASSERTION: nsNSSComponent relies on profile manager to wait for synchronous shutdown of all network activity: 'mIsNetworkDown', file /Users/moztest/comm/main/src/mozilla/security/manager/ssl/src/nsNSSComponent.cpp, line 2590 (at least on my mac).
(In reply to Mark Banner (:standard8) from comment #26) > ###!!! ASSERTION: nsNSSComponent relies on profile manager to wait for > synchronous shutdown of all network activity: 'mIsNetworkDown', file > /Users/moztest/comm/main/src/mozilla/security/manager/ssl/src/nsNSSComponent. > cpp, line 2590 > ###!!! ASSERTION: nsNSSComponent relies on profile manager to wait for > synchronous shutdown of all network activity: 'mIsNetworkDown', file > /Users/moztest/comm/main/src/mozilla/security/manager/ssl/src/nsNSSComponent. > cpp, line 2590 Hmm, that sounds like I need a while (gThreadManager.currentThread.hasPendingEvents()) before the .processNextEvent ?
Unfortunately that doesn't work.
Comment on attachment 591980 [details] [diff] [review] Updated patch Review of attachment 591980 [details] [diff] [review]: ----------------------------------------------------------------- Weird, I just was retrying this to see if I could debug the failure, and with this additional patch it worked: diff --git a/mailnews/news/test/unit/test_uriParser.js b/mailnews/news/test/unit/test_uriParser.js --- a/mailnews/news/test/unit/test_uriParser.js +++ b/mailnews/news/test/unit/test_uriParser.js @@ -167,5 +167,7 @@ function run_test() { // The password migration is async, so trigger an event to prevent the logon // manager from trying to migrate after shutdown has started. var gThreadManager = Cc["@mozilla.org/thread-manager;1"].getService(); - gThreadManager.currentThread.processNextEvent(true); + var thread = gThreadManager.currentThread; + while (thread.hasPendingEvents()) + thread.processNextEvent(true); } Not sure what I was doing wrong before. ::: mailnews/news/src/nsNewsFolder.cpp @@ +1281,5 @@ > } > NS_FREE_XPCOM_ISUPPORTS_POINTER_ARRAY(count, logins); > NS_ENSURE_SUCCESS(rv, rv); > > + // If there is nothing to migrate, then do othing nit: othing -> nothing
Attachment #591980 - Flags: review?(mbanner) → review+
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 13.0
Depends on: 783479

More then 10 years ago, and the bug is still alive. I have to put in the password 3-4 times everytime... Any workaround?

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

Attachment

General

Created:
Updated:
Size: