Closed Bug 95397 Opened 23 years ago Closed 9 years ago

Mozilla should not ask the same question in more than one window.

Categories

(Core :: Networking, enhancement)

x86
All
enhancement
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mozilla-bugs, Unassigned)

References

(Depends on 1 open bug)

Details

I am not sure if this is a PSM bug, so I am filing it as "unconfirmed". Reproducible: always Steps to reporduce: 1) Open two windows with two different URLs to a site that requires authentication (for example, run mozilla -remote 'openurl(http://members.spamcop.net/,new-window)' mozilla -remote 'openurl(http://members.spamcop.net/tst,new-window)' ) Expected: The two windows share a single authentication dialog. Actual: Each window has its own. This is the problem not only with basic auth dialog, but with other auth dialogs (e.g. NNTP) as well. Note that this seems to work correctly if both windows go to the same URL. Obviously, to be able to solve this problem, the dialog needs to know what it is authentication for (e.g. host&real for HTTP, host&group for NNTP, etc). This may mean that this bug depends on bug 51696 (or bug 38008?) for basic auth and bug 85637 for NNTP. P.S. I am currently using 2001080600 on RedHat 7.1
Is this really expected? Can't one set up a site that has exactly the same host, but will require different auths for different URLs? P3 t->future.
Priority: -- → P3
Target Milestone: --- → Future
Sure, one can have different auth info for different URLs on the same host, but then realms should be different as well. Anyway, if the wallet (IMHO correctly) treats the auth info for same host-realm pair as being the same, why shouldn't the password prompt do the same?
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: ckritzer → junruh
Should the PSM password dialog be considered another issue or a part of the same one? It's pretty annoying to come back to the machine and to realize that I suddenly have dozens of copies of the PSM password dialog... Nominating it for 1.0, IMHO it's an important usability issue.
Keywords: mozilla1.0
Are you talking about the SDR web passwords? Do you use encrypt to keep your web password? If this is an issue with web passwords (rather than cert password for client authentication), then the trigger for the password in not in PSM code. I've never come to my desk to find dozens of "PSM password" dialogs waiting for me. By "PSM password" do you mean the "Please enter the Master Password for the Software Security Device"?
> By "PSM password" do you mean the "Please enter the Master Password for the > Software Security Device"? Yes. > I've never come to my desk to find dozens of "PSM password" dialogs waiting for me. Steps to reproduce: 1) Make sure you have "Encrypt sensitive information" enabled. 2) Set up an NNTP account for a server that requires authentication (I am not sure if passwd-protected POP or IMAP will act the same; if you do not have access to passwd-protected NNTP server, you can try to emulate one by using user_pref("mail.server.servernn.always_authenticate", true); ). 3) Make sure that auth information for that server is stored in the wallet. 4) Set biff ("check for new messages every 1 minutes") on that account. 5) Restart Mozilla (logging out of Password Manager will probably work the same, but haven't tried it). 6) Go for lunch. Expected: when you come back, you have at most one "master password" dialogs waiting for you. Actual: you'll have a *lot* of them. It seems that every time Mozilla tries to check for new messages, the server will ask for authentication and Mozilla will prompt for the "master password". Note that if you do the same thing, but without storing the NNTP auth info in the wallet, you'll get the same crazy number of "please enter username for news access" prompts, so this behaviour is in no way specific for "master password". > If this is an issue with web passwords (rather than cert password for client > authentication), then the trigger for the password in not in PSM code. As I said in the initial report, I am not sure if this is a PSM issue or not. IMHO, this is not an issue with some *particular* promts (NNTP auth, web auth, master password, etc), but with prompts *in general*. IMHO, there needs to be some general framework for coding "I want to prompt for something, but if I already did it, just let's wait together on an existing dialog".
Well, in this case this is not something I can do anything about. Browser->general to see if somebody wants to take it.
Assignee: ssaux → asa
Component: Client Library → Browser-General
Product: PSM → Browser
QA Contact: junruh → doronr
Version: 2.0 → other
->apps
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
don't think this belongs in xp apps. back to browser-general. perhaps somewhere in networking or js?
Assignee: pchen → asa
Component: XP Apps → Browser-General
QA Contact: sairuh → doronr
well that was fun.
Assignee: asa → neeti
Component: Browser-General → Networking
QA Contact: doronr → benc
Target Milestone: Future → ---
Timeless, are you sure it belongs to Networking? Disallowing more than one "Please enter the Master Password for the Software Security Device" windows definitely seems outside of networking and it wasn't decided yet if that is the same problem as with other auth dialogs, or a separate one.
No, i wholeheartedly thought it belonged to PSM, but we crossed and burned that bridge already. alternatively, networking could cause the system to block preventing further reloads (actually if this is exclusively a mail issue then mailnews:networking *, but your original description was for http...) or just remember it already had a pending question and try to focus it again (actually this might be docshell or something but i'm not sure which of those things it'd be).
cc'ing darin
Yet another instance of this problem - just came back to my machine to find out 154 instances of the "The newsgroup xxx does not appear to exist on the host yyy. Would you like to unsubscribe from it?" question (xxx and yyy were the same in all 154 of them). To reproduce, try removing one of the newsgroups you are subscribed to from the server while Mozilla is running with "check for new messages every 1 minutes" enabled...
Summary: Mozilla should not ask for the same password in more then one window. → Mozilla should not ask the same question in more then one window.
Summary: Mozilla should not ask the same question in more then one window. → Mozilla should not ask the same question in more than one window.
is this still a problem?
Yes, BuildID 2002100119 (trunk) still has it. I didn't go though all 3 scenarious (original report, comment #6 and comment #14), but tried some of it and was able to get both two "Master Password" dialogs and two "basic auth" dialogs (for the same thing).
Can we get some updated steps? I'm not convinced what is going on is a real problem.
> Can we get some updated steps? What's wrong with *three* sets of existing ones? I just tried the ones in the original report and the ones in comment #6, both still behave exactly the same. Have not tried reproducing comment #14, but I expect it to be exactly the same as well... > I'm not convinced what is going on is a real problem. Well, the thing with having multiple dialogs is that you have to deal with them one-by-one. So when you are faced with hundreds of dialogs, you are more or less forced to quit (even kill, if the dialogs are modal) Mozilla. And even then, if you had enough dialogs to push X deeply into swap (if you'd been away for a day while biff is set for every minute, that is likely to happen), even after Mozilla is killed, it can take X several *minutes* of slowly getting rid of these windows one-by-one to get out of swap and stop trashing. So, in worst case scenario this can be even worse than a crash... And even if you end up with two-tree windows as opposed to several hunderds of those, it is still pretty annoying that you have to type the exact same thing in every one of them...
"real" probably should have been "really networking". All I care about at this point, is figuring out if this is a networking problem or not. I'll leave that to darin and dougt, because I don't know where password manager intersects w/ these user events.
darin: is this a networking bug?
Assignee: neeti → darin
yes, i think this is a networking bug. we should delay the second prompt until the first prompt returns. we can probably add a flag to the http auth cache entry to indicate a prompt in progress, and then add some kind of hook to be notified when the prompt returns. shouldn't be that difficult to implement. in my mind, this is an enhancement bug. marking as such, and futuring (not sure when i'll get around to fixing this).
Severity: normal → enhancement
Status: NEW → ASSIGNED
Keywords: mozilla1.0
Priority: P3 → P5
Target Milestone: --- → Future
Should I file a separate bug for the "Master Password" dialog? I doubt it's networking too...
yes, IMO that is a different bug.
Master Password one is filed as bug 177175.
Depends on: 177175
Is this bug really dependant on that bug? If so, we should update the reference because it was duped.
This bug definitely depends on 96896. I am not convinced 177175 is really a dup, so will keep it too in case it's reopened.
Depends on: 96896
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking
Target Milestone: Future → ---
Does the first window then own the prompt? What happens if I Alt-Tab to the second window? Does it just hang, waiting for the prompt to be answered? How will the user know they have to answer the prompt in the first window? There is some code recently that I think detaches prompts from any window, but I' m not sure this is working very well.
I think the answer to that is to invert this bug report. If the same question blocks progress in multiple windows, continue using multiple alerts, one for each window. But if the question is answered affirmatively in any of the alerts, all its doppelgangers should also be dismissed.
Depends on: 369963
Depends on: 348997
Depends on: 356097
Depends on: 346658
OS: Linux → All
Depends on: 230190
Depends on: 499233
Depends on: 515521
Depends on: 625051
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.