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

Status: NEW

(Toolkit :: Content Prompts, defect, P5)

Description

[Nickolay_Ponomarev]

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

Comment 2

[Nickolay_Ponomarev]

An alternative suggestion from faaborg in bug 407268 comment 8:
"What about switching these prompts to content area messages instead of dialogs."

Comment 3

[Rob]

Is this to be added to the Master Bug 411085 (this is a Dupe?)
Rob

Comment 4

[[e-mail] (:bhearsum)]

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.

Comment 6

[Jean Claveau]

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

[Jesse Ruderman]

This is most likely to be fixed by making the dialog tab-modal (bug 613785)

Comment 8

[Florian Bender]

What's the rationale behind marking this as fixed? Doesn't seem to be fixed yet.

Comment 9

[Patrick McManus [:mcmanus]]

thanks - just a mistake when doing a whole component triage.

Comment 11

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 12

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 13

[Tom S. (please needinfo tschuster)]

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

Comment 14

[Emma Zühlcke [:emz]]

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.

Comment 15

[BugBot [:suhaib / :marco]]

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

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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

[scott]

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

Comment 18

[Valentin Gosu [:valentin]]

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

Comment 19

[Dão Gottwald [:dao]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #18)

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

This is only really the very last part of the story here. If we want callers to specify if they want the tab switch, the interesting parts of the fix will be in our internal prompter API and its consumers.

Comment 20

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:mtigley, could you have a look please?

For more information, please visit BugBot documentation.

Comment 21

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:mtigley, could you have a look please?

For more information, please visit BugBot documentation.

Comment 22

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:mtigley, could you have a look please?

For more information, please visit BugBot documentation.