HTTP auth in a background tab shouldn't cause any dialogs to be displayed
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
People
(Reporter: asqueella, Unassigned)
References
Details
(Whiteboard: [necko-backlog])
+++ This bug was initially created as a clone of Bug #407268 +++ From dolske in bug 407268 comment 7: ---------------------------------- Not showing an HTTP auth prompt for background tabs [...] [This issue is] still relevant. Basically, it's the HTTP auth equivalent of bug 513534... If you just started the browser, it's likely that you want to go do something, not be forced to deal with a number of HTTP auth prompts for tabs you're not interested in at the moment. Bug 223636 will also help here, in that if the login is automatic you won't be prompted (although there's still the possibility of triggering a master password, ala bug 513534). ----------------------------------- A possible solution to this bug could be bug 399583 (show HTTP auth in the tab instead of in a modal dialog), as long as the solution will not cause master password to be shown for background tabs.
Reporter | ||
Comment 2•15 years ago
|
||
An alternative suggestion from faaborg in bug 407268 comment 8: "What about switching these prompts to content area messages instead of dialogs."
Is this to be added to the Master Bug 411085 (this is a Dupe?) Rob
Comment 4•13 years ago
|
||
For anyone who has a lot of tabs with authentication in their session this bug is an awful paper cut. I get hit with it almost every time I start my browser.
Updated•13 years ago
|
Comment 6•12 years ago
|
||
As a webdev, I always have a lot of phpmyadmin pined tabs. They autoload even if I don't load the tabs of the previous session (wich is a good behaviour). Admins often use http auth because their don't care design and it's simple to setup and safe. I see two ways to make a better http auth : + Allow autologin with a checkbox. + Change the dialog to an "in tab" dialog as the new js alert dialog. In this second case, there is only one trap that can confuse people : The tab seem opened without being really because it is stuck asking for id. A layer over the favicon indicating this status (a key or anything else) or any other kind of notification would be a good workaround. Thanks in advance.
Comment 7•9 years ago
|
||
This is most likely to be fixed by making the dialog tab-modal (bug 613785)
Updated•8 years ago
|
Comment 8•8 years ago
|
||
What's the rationale behind marking this as fixed? Doesn't seem to be fixed yet.
Comment 9•8 years ago
|
||
thanks - just a mistake when doing a whole component triage.
Comment 11•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Comment 12•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Comment 13•4 years ago
|
||
I just tested this with bug 613785 fixed and we still switch to the background tab that requested HTTP auth.
Comment 14•4 years ago
|
||
This is the code that triggers the tab switch:
https://searchfox.org/mozilla-central/rev/5efefd3ef214ed6d3234ba245c1da3004ead94e0/browser/base/content/tabbrowser.js#5331
Would be nice if prompt callers could specify if they want a tab switch.
Updated•2 years ago
|
Comment 15•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates and 14 votes.
:kershaw, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Comment 16•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Comment 17•1 year ago
|
||
(In reply to Paul Zühlcke [:pbz] from comment #14)
This is the code that triggers the tab switch:
https://searchfox.org/mozilla-central/rev/5efefd3ef214ed6d3234ba245c1da3004ead94e0/browser/base/content/tabbrowser.js#5331Would be nice if prompt callers could specify if they want a tab switch.
I absolutely would like an option to turn that off. Comment 6 in this thread is my issue exactly with some internal applications. IMO it's unacceptable for a website/tab A to be able steal my focus from website/tab B. Materializing has abused this behavior before.
Comment 18•1 year ago
|
||
(In reply to Paul Zühlcke [:pbz] from comment #14)
This is the code that triggers the tab switch:
https://searchfox.org/mozilla-central/rev/5efefd3ef214ed6d3234ba245c1da3004ead94e0/browser/base/content/tabbrowser.js#5331
Moving to Firefox::Tabbed browser based on this comment.
Clearing priority and severity to get this re-triaged.
Description
•