450873 - HTTP Auth prompts and Javascript alerts should open in background

Status: RESOLVED DUPLICATE of bug 59314

(Firefox :: Tabbed Browser, enhancement)

Description

[Anant Narayanan [:anant]]

Visiting a site that requires HTTP Authentication and then switching to another tab results in focus returning to the original tab prompting for a username and password.

The tab requiring auth may not be the active tab (eg: I option-click on a link that leads to a site requiring auth); from a user-experience perspective this can be extremely annoying (eg: I was typing something in my active tab when the active tab suddenly switched).

The same goes for Javascript alerts. In Safari, the active tab is not switched, but instead an alert icon is displayed against the tab. The auth dialog / alert is displayed only when the user manually switches to that tab (See Attachment).

Much better UX in my opinion :)

Sorry if this is a dupe.

Comment 1

[Anant Narayanan [:anant]]

Attachment: Auth dialogs and Javascript alerts are backgrounded in Safari

Comment 2

[Steven Michaud [:smichaud] (Retired)]

The problem you report happens on Windows and Linux (in addition to OS
X), and with both Firefox 2.X and Firefox 3.X.

And yes, the problem doesn't happen with Safari (on OS X), IE 7 (on
Windows XP) or Konqueror 3.5.8 on Linux (though these three all behave
differently from each other).

But the Firefox behavior is consistent and has been around for a
while.  And (as I noted above) there doesn't seem to be agreement on
what _is_ the correct behavior.  So I don't think Firefox's behavior
is really incorrect.  In effect you're asking for a feature change (or
a new, optional, alternative to the current behavior).

So I'm changing the Platform to All, and I'm marking this as a request
for an enhancement.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

> And yes, the problem doesn't happen with Safari (on OS X), IE 7 (on
> Windows XP) or Konqueror 3.5.8 on Linux (though these three all
> behave differently from each other).

Actually, IE 7 seems to behave the same way as Safari (3.1.2 on OS X
10.5.4).  But Konqueror 3.5.8 behaves differently.

And Opera 9.5.1 (on OS X) behaves like Safari (and IE 7) while Shiira
2.2 (another WebKit browser) behaves like Konqueror.

So (maybe) nobody else behaves like Firefox.  But I'm still not
convinced the Firefox behavior is wrong.

Comment 4

[Anant Narayanan [:anant]]

There is never a wrong or right behavior for things concerning user experience or interfaces - there is only better or worse :-)

What I'm trying to say is that current behavior is not optimal because it focuses on elements (in this case, tabs) that were not explicitly requested by the user, much like popups. If we block popups on websites, I don't see a reason why we shouldn't restrain our own 'popups' to make sure they don't appear when the user clearly doesn't want them to (because the user is now focusing on another tab and wishes the earlier tab to remain in the background).

Comment 5

[Steven Michaud [:smichaud] (Retired)]

I don't normally do GUI stuff, and I'm actually a rather poor judge of
what makes a good GUI ... I'm willing to use just about anything :-)

Mike, I've cc-ed you because you're likely to be a much better judge
of what we should do here.

Comment 6

[Jan Binder]

Especially the HTTP authentication popups are annoying when resuming a session and not using the built-in password manager. Popups do not follow the spirit of tabbed browsing, which is keeping pages seperated.

For the "browser x is not doing that, so it can't be good" agrument, the integrated ("backgrounded") search bar in Firefox is an example of doing things right: The view of the web page (what a browser is made for) is not hindered like in IE6 or Konqueror. 

"Backgrounding" popups would be a logical step, as we are:
1) Keeping messages/authentication requests where they belong: in the tab that caused the popup, preserving its context.
2) Not interrupting the user. Popups are quite rude, even more so if you happen to look at a different tab. They should only be used if something *really* important has happened and requires your *immediate* attention. The web is not such a time-critical environment.

Comment 7

[Kamil Sartys]

There is a good reason why these (annoying) HTTP-AUTH-Popups should be replaced by some kind of "AUTH page": Bug 216466

FF is very inconsistent and inconsequent on this. Why have the popups for network errors been removed but the auth modal dialog is still around?

Comment 8

[Ralph]

I agree this behavior can get really bothersome, and it's a major issue of the UI.

A special case is when resuming a previous session. If you have more than one tab open for the same authenticated site, then you will get as many requests as tabs you have, even if it's the same and you did enter the password, so that's another flaw (IMHO).

Overall, I believe these alerts being constrained to the container tab (and not taking focus) is the best way, but also helping the user notice the tabs with an alert in it maybe by a (theme-configurable) flashing or styling.

Comment 9

[Ralph]

Maybe this is a duplicate of bug 59314?
—I guess I'll double-post.

Comment 10

[Nickolay_Ponomarev]

This report discusses several improvements, all already reported several times. E.g. bug 59314 for alert()s and bug 399583 for HTTP auth. Please report one issue per bug.

Comment 11

[Nickolay_Ponomarev]

An update: even though bug 59314 was fixed, we still focus the tab when it displays the alert() - now tracked in bug 332195.