Open Bug 516781 Opened 15 years ago Updated 2 years ago

HTTP auth in a background tab shouldn't cause any dialogs to be displayed

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
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.
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
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.
Assignee: kaie → nobody
Component: Security: UI → Networking: HTTP
QA Contact: ui → networking.http
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.
This is most likely to be fixed by making the dialog tab-modal (bug 613785)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
What's the rationale behind marking this as fixed? Doesn't seem to be fixed yet.
Flags: needinfo?(mcmanus)
thanks - just a mistake when doing a whole component triage.
Status: RESOLVED → REOPENED
Depends on: 613785
Flags: needinfo?(mcmanus)
Resolution: FIXED → ---
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3

I just tested this with bug 613785 fixed and we still switch to the background tab that requested HTTP auth.

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.

Severity: normal → S3

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.

Flags: needinfo?(kershaw)

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.

Flags: needinfo?(kershaw)

(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

Would 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.

(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.

Severity: S3 → --
Status: REOPENED → NEW
Component: Networking: HTTP → Tabbed Browser
Priority: P3 → --
Product: Core → Firefox
You need to log in before you can comment on or make changes to this bug.