Closed
Bug 391100
Opened 17 years ago
Closed 17 years ago
Http auth prompt from other tabs displays over current tab
Categories
(Core Graveyard :: Embedding: APIs, defect)
Core Graveyard
Embedding: APIs
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: bc, Assigned: Biesinger)
References
Details
(Keywords: regression, relnote, Whiteboard: [sg:low] post 1.8-branch)
Attachments
(1 file, 1 obsolete file)
27.08 KB,
patch
|
bzbarsky
:
review+
jst
:
superreview+
bzbarsky
:
approval1.9+
|
Details | Diff | Splinter Review |
Bug 277574 has regressed on the trunk. I've confirmed with a recent trunk on windows and as far back as 1.9a1 on linux. Steps to reproduce: 1. load a site in one tab. 2. load another site requiring basic authentication in a background tab. 3. switch back to the first tab. Expected results: When the authentication dialog appears, the active tab should be switched to the tab presenting the dialog. Actual results: The first tab remains active while the authentication dialog from the second tab appears. Easy test on the command line: firefox -P profilename http://cnn.com/ http://bclary.com/log/2007/08/06/
Flags: blocking-firefox3?
Updated•17 years ago
|
Flags: in-litmus?
Comment 1•17 years ago
|
||
Looks like this was regressed by bug 265780 - the nsPromptService::Prompt* methods don't have any nsAutoWindowStateHelper helpers that launch the DOMWillOpenModalDialog event.
Severity: normal → major
Component: Tabbed Browser → Embedding: APIs
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: tabbed.browser → apis
Hardware: PC → All
Updated•17 years ago
|
Flags: blocking1.9?
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → cbiesinger
Assignee | ||
Comment 2•17 years ago
|
||
this makes nsIPromptService2::PromptAuth also dispatch the necessary event. I'm not sure that that's correct behaviour though...
Assignee | ||
Comment 3•17 years ago
|
||
this moves the event dispatching stuff into the prompt service (as various people suggested in bug 277574 already)
Attachment #276585 -
Attachment is obsolete: true
Attachment #276858 -
Flags: superreview?(jst)
Attachment #276858 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 4•17 years ago
|
||
Oh, I should probably mention, the cause of this bug is that passwordmanager uses the prompt service method to show the password dialog. Previously, it used the nsIAuthPrompt method. So bug 265780 didn't really cause this directly.
Comment 5•17 years ago
|
||
Comment on attachment 276858 [details] [diff] [review] patch Looks good if you get rid of the extraneous newlines after some of the blocks of code you added (some places you added two newlines after the block).
Attachment #276858 -
Flags: review?(bzbarsky) → review+
Updated•17 years ago
|
Attachment #276858 -
Flags: superreview?(jst) → superreview+
Assignee | ||
Updated•17 years ago
|
Attachment #276858 -
Flags: approval1.9?
Comment 6•17 years ago
|
||
Comment on attachment 276858 [details] [diff] [review] patch a=bzbarsky
Attachment #276858 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 7•17 years ago
|
||
Checking in windowwatcher/src/nsPrompt.cpp; /cvsroot/mozilla/embedding/components/windowwatcher/src/nsPrompt.cpp,v <-- nsPrompt.cpp new revision: 1.30; previous revision: 1.29 done Checking in windowwatcher/src/nsPrompt.h; /cvsroot/mozilla/embedding/components/windowwatcher/src/nsPrompt.h,v <-- nsPrompt.h new revision: 1.11; previous revision: 1.10 done Checking in windowwatcher/src/nsPromptService.cpp; /cvsroot/mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp,v <-- nsPromptService.cpp new revision: 1.35; previous revision: 1.34 done Checking in windowwatcher/src/nsPromptService.h; /cvsroot/mozilla/embedding/components/windowwatcher/src/nsPromptService.h,v <-- nsPromptService.h new revision: 1.14; previous revision: 1.13 done Checking in windowwatcher/src/nsWindowWatcher.cpp; /cvsroot/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp,v <-- nsWindowWatcher.cpp new revision: 1.135; previous revision: 1.134 done
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Comment 8•17 years ago
|
||
Ah... so do embedding apps (like Camino, say) use this code? Or did we just screw them over? They _do_ use nsPrompt, right?
Assignee | ||
Comment 9•17 years ago
|
||
oh. um. I guess we may have, yeah... guess they'll have to add this code to their promptservice implementation if they want it
Comment 11•17 years ago
|
||
Not really sure who the camino folks who should see this are, if any...
Comment 12•17 years ago
|
||
Camino is still using nsIAuthPrompt for HTTP auth, so we're fine (unless I'm misunderstanding, but tests look fine in a fresh build).
Comment 13•17 years ago
|
||
The question is whether you provide your own prompt service implementation or whether you're using the default one, complete with XUL dialogs..... Sounds like the latter.
Comment 14•17 years ago
|
||
Although given the existence of camino/src/browser/CocoaPromptService.mm maybe not!
Assignee | ||
Comment 15•17 years ago
|
||
Well what this change potentially breaks isn't the dialogs as such, only the switching to that tab when a modal dialog/auth dialog is shown from it.
Comment 16•17 years ago
|
||
Right, we have our own prompt service. It's been set up to force a switch to the tab the prompt came from since we fixed bug 262887 for Camino though, all handled in our code.
Updated•17 years ago
|
Flags: wanted1.8.1.x-
Flags: wanted1.8.0.x-
Whiteboard: [sg:low] post 1.8-branch
Updated•17 years ago
|
Group: security
Comment 17•17 years ago
|
||
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8) Gecko/2007091216 GranParadiso/3.0a8 and the steps to reproduce from this bug
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•