Closed Bug 567804 Opened 14 years ago Closed 11 years ago

Convert HTTP Auth modal dialog to a doorhanger notification

Categories

(Toolkit :: Password Manager, defect)

Product:
Toolkit
Component:
Password Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: fryn, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug,
URL
)

Details

(Whiteboard: [doorhanger])

Attachments

(2 files)

Opera's approach for the HTTP Auth
43.20 KB, image/png
Details
Prompt per tab is needed, Opera example in image.
54.60 KB, image/png
Details 
HTTP Auth could be better served as a doorhanger notification to unify UI, prevent spoofing, etc. See URL for design and other details.
Depends on: 562258
Depends on bug 398776 for the doorhanger notification API.

Depends on bug 562258 to make prompts tab-modal.

Depends on bug 567814 to properly integrate 'Remember Password' so we get the following UI flow:

auth doorhanger prompt ->
incorrect credentials ->
auth doorhanger prompt ->
correct credentials ->
show remember password doorhanger

instead of:

auth doorhanger prompt ->
incorrect credentials ->
show remember password doorhanger *BAD* ->
auth doorhanger prompt ->
hide remember password doorhanger *BAD* ->
correct credentials ->
show remember password doorhanger
Depends on: 567814
(In reply to comment #1)

> instead of:
> 
> auth doorhanger prompt ->
> incorrect credentials ->
> show remember password doorhanger *BAD* ->

Hrm. This does seem to be more of a problem than it is currently (where the modal auth dialog takes attention away from the "remember password" notification bar that briefly appears.

To do this right we'd probably add some kind of callback from the network code, so that when the first time a newly-provided login is used, it tells us if it succeeded (401 or not).

An interm hack might be to just add a short time delay to the remember-password prompt, which at least avoids the problem for fast-to-respond servers.
OS: Mac OS X → All
Hardware: x86 → All
Status: NEW → ASSIGNED
Don't think I will have time to do this in the near future.
Assignee: fryn → nobody
Status: ASSIGNED → NEW
Opera had implemented a doorhanger-like HTTP-Auth notification with server name, message, and "Remember Password" checkbox included in the dialog. It might be a great practice in design to avoid unnecessary "Remember Password doorhanger." (So is it a parity-opera?)
(In reply to comment #2)
> An interm hack might be to just add a short time delay to the remember-password
> prompt, which at least avoids the problem for fast-to-respond servers.

Chromium actually waits until a response is returned to show the remember-password prompt. This way, it can run its code to detect whether the login was successful and also avoid showing the prompt twice if the credentials were incorrect. We could use that interim hack in the short term, but I think Chromium's flow may be a better long term solution, even if it does delay the prompt a second or two.
Blocks: 411085
I also filed bug 613785 to convert this dialog to be tab-modal.  We should decide which approach to take.
Keywords: uiwanted
A doorhanger might not be ideal after all; the auth dialog is something that we don't want to be too easily dismissable, since it's almost always required to access the page.
Doesn't it make sense to keep a logical and visual separation between dialogs the page produces (alerts, HTTP auth) and dialogs Firefox produces to improve user experience (Saving passwords, etc.)?  This breaks down--geolocation already uses doorhanger--but it seems they should be differentiated?
We're trying to draw the distinction between privacy sensitive (left side of site identity block with a persistent idicator), important site permissions (identity block but no persistent indicator), and unimportant js dialogs (not chrome at all, basically as if the site programed their own lightbox in the content area)
See Also: → 399583
We could have it spawn from the identity block, but it should be tab-*modal*, since we don't want to produce a bunch of "Unauthorized" error pages, because the user accidentally dismissed it. The problem is that we still have the option to display tabs-on-bottom, which makes displaying tab-modal prompts from the navigation bar tricky, since they would cover the tab bar. I think tabs-on-bottom should just be removed, but that's a question from another day.
I think something like we have done for tab-modal JS dialogs would be best for HTTP Auth, it should be tab-modal. The only problem there is how we avoid spoofability (not that the current app-modal dialog avoids it, really).
Whiteboard: [doorhanger]
I think the ability to make this a doorhanger depends heavily on how Bug 647010 is resolved. It would be *very* misleading to have the HTTP auth doorhanger pointing to the site identity block, if the site to which the user is authenticating is actually a different site.
The bug 399583 that is now a dup of this bug blocks the bug 616843 , shouldn't this bug block 616843 too ?
(In reply to comment #14)
> I think the ability to make this a doorhanger depends heavily on how Bug 647010
> is resolved. It would be *very* misleading to have the HTTP auth doorhanger
> pointing to the site identity block, if the site to which the user is
> authenticating is actually a different site.

Absolutely. Also, no doorhangers are currently modal, and we might want the HTTP Auth UI to be (tab-)modal to avoid accidental dismissal and prevent unnecessary 401's.
See Also: 399583 → 
I'm not convinced this is a great idea. Doorhangers aren't meant to be modal, are they? If some are and others aren't that's quite an inconsistency.

What's the benefit of making this a doorhanger as opposed to a tab-modal prompt? The benefits I found in the first comment and the linked URL are:

* unify UI
* make it easily dismissable
* not phishable/spoofable
* make it accessible

"Unify UI" is a great goal, but in this case it'll make something inconsistent (the modality of the prompt). "Make it easily dismissable" is not applicable for the same reason - in fact it's probably undesirable, if http auth is a requirement to view some content. Besides, there's no reason why a tab-modal prompt can't also be easily dismissable (assuming this means "click outside to dismiss").

"Not phishable/spoofable" currently depends on bug 647010. Moreover, I'm not really sure what makes doorhangers less spoofable - is it that small bit of the triangle that overlays the 4-pixel chrome border? Something tells me there are a lot of people who wouldn't notice the difference if a site showed a spoofed doorhanger that's simply moved down so as not to overlap that border. (except for those who disable Tabs On Top of course). Perhaps "there exists a way to tell if it's spoofed" is a better way to phrase it.

Of course an attacker could just send whatever headers are required to trigger the real http auth box - which is surely much less work than trying to spoof it. Wouldn't that achieve all the same goals anyway, thus making "unspoofable" a goal that doesn't really matter?

I'm not sure what "accessible" is referring to.

(In reply to comment #9)
> We're trying to draw the distinction between privacy sensitive (left side of
> site identity block with a persistent idicator), important site permissions
> (identity block but no persistent indicator), and unimportant js dialogs (not
> chrome at all, basically as if the site programed their own lightbox in the
> content area)

Is there really a difference between HTTP auth and site's own lightbox with standard login details (which lots of sites have)? The implementation difference is surely irrelevant from the user perspective - they are still entering a username and a password, and those are still sent to whoever requested them. Perhaps comment #9 highlights exactly why this should NOT be a doorhanger?
I'd prefer a full-content-area page for HTTP auth. That way, you can just look at the URL bar to know which site you're logging in to.
If spoofability is an issue, then it's been an issue forever, since if you know what the user's browser looks like you can already spoof window-modal prompts well enough to fool most users.  As others have said, where's the danger in people spoofing password prompts for themselves?

I don't think the current windowhanger UI is appropriate, because it's by design unobtrusive; password prompts need to grab attention.  Opera deals with this by making the doorhanger-like UI very large, so it's clearly the focus of the tab.  That seems to work.  Chrome does have tab-modal dialogs for this.
>That way, you can just look at the URL bar to know which
>site you're logging in to.

Ideally a notification that is more directly visually associated with the site identity block would result in people being more likely to look at the URL.

>because it's by
>design unobtrusive; password prompts need to grab attention.

It's desined to be interactively unobtrusive, since currently they are click outside to close (this one however would be modal).  But visually, people seem to be noticing them very well.  For instance, amazingly a lot of users believe that Firefox 4 introduced the feature of having a password manager.

I would like to keep httpauth as a doorhanger, since it will then match the interactions we are designing for account manager and password manager.
(In reply to comment #21)
> It's designed to be interactively unobtrusive, since currently they are click
> outside to close (this one however would be modal).  But visually, people seem
> to be noticing them very well.  For instance, amazingly a lot of users believe
> that Firefox 4 introduced the feature of having a password manager.

Considering banner blindness ( https://secure.wikimedia.org/wikipedia/en/wiki/Banner_blindness ) and that notification bars look like they could be part of the web page (they are spoofable), this makes a lot of sense!
I think the issues of spoofability are really just a slightly different bug.  When Firefox goes to a site that needs a password prompt, it should handle HTTPS certificate checking first, then update the URL bar so that it actually indicates what site the user is looking at (and blank the content area because the password prompt has nothing to do with the site that the user just came from).  Then Firefox can safely render the password prompt however it likes, because it works just like a site with a form with a password field on it.

(Chrome gets this almost right.  It just doesn't show the URL bar in green to indicate a secure connection until after the user enters a password.)

Right now, Firefox will happily show me a prompt that looks like it's coming from gmail when it's really the site that I just clicked a link to that's doing the prompting.
A story from today:

I was working with firefox, at the moment i got 28 tabs opened. From time to time, firefox got busted and crashes. So I report the crash and start firefox again. Another time is simply, I quit firefox and restart it again manually. The problem occurs, when Firefox starts again. That way it loads all tabs again and once there is just one site that needs http auth, I need to login there in order to use my browser again - WTF? I don't want to work on that site again, maybe later, that's why it is still opened, or I need a lookup over there from time to time. Nope, I need to login there or dismiss the auth dialog in order to use my browser at a whole, that's freaking me out.
So, just from a UI/Usability perspective, please bound it to a tab and not the whole browser session at all.
Thanks.
Bug 516781 and bug 223636 should also help for the session-restore cases.
Opera, Google Chrome, Maxthon - don't block all tabs then one tab need http password entrty. Even Internet Explorer 8.0 don't block, until you activate tab, wich wait password entry and flashing by tab title.
Not sure how to answer. Summon Limi for help.:)
Assignee: nobody → limi
Keywords: uiwanted
Is this still the plan for authentication? I suffer from this almost every day as I have a HTTP auth tab in my app tabs. The browser will interrupt startup to request my credentials. I was wondering if I could spend some time on this, but it would be helpful if there is some consensus from UX and security about what some of the sticking points are.
(In reply to Dirkjan Ochtman (:djc) from comment #30)
> Is this still the plan for authentication? I suffer from this almost every
> day as I have a HTTP auth tab in my app tabs. The browser will interrupt
> startup to request my credentials. I was wondering if I could spend some
> time on this, but it would be helpful if there is some consensus from UX and
> security about what some of the sticking points are.

Hi Dirkjan, may I suggest a workaround? Set the app tabs to be lazily loaded upon startup, so the popup doesn't come in your way until you select that specific tab.
In about:config set 
browser.sessionstore.restore_pinned_tabs_on_demand to TRUE
I hope this is fixed, not sidestepped.  (Lazy-loading tabs isn't a good workaround--if the browser doesn't have a tab loaded and ready to go when I need it, it's waited too long.  browser.sessionstore.restore_on_demand needs to not be the default...)
I think restore_on_demand should stay the default.  I spend most of my time connected to a spotty campus WiFi network, which redirects everything to their login page between when you connect and when you log in.  When I restart the browser with restore_on_demand off, I get a hundred tabs of the login page, which usually loses the original URL in every tab.  What I would like to see is an infobar when an on-demand load occurs which summarizes what's happening and has a button to bring up the relevant settings.  (I expect there's another bug where this comment would actually be on-topic, if someone can let me know which I'll copy it there too.)
Please, can we keep this on-topic? This bug is not about whether Firefox should restore (pinned or otherwise) tabs on demand or not. Like Glenn, I would simply like a single tab's authentication dialogs not to block me from using the entire browser.
+1 for fixing this bug. It's extremely annoying to have all the browser blocked for one auth dialog; not to mention cases when you need to copy the credentials from other tab! Let's bring Firefox into 2012.

I'm almost tempted to disable tabs altogether, the current auth dialogue I guess it's a legacy from pre-tab era.
Assignee: limi → nobody
I cannot understand how this is not solved yet! Even midori browser has an authentication dialog that it is not modal. I use to enter in several pages that require HTTP basic auth and this bug is killing my work. I have some passwords stored in the webmail, so when some of this windows opens up I usually have to open another browser as I cannot use firefox meanwhile!
If this is not solved in near future I'll have to change to chromium :(, sad but true.
In next releases are scheduled things like "make favicons larger" but this bug was reported two years ago and is still marked as new. I think mozilla is loosing the end user experience point of view, dramatically.
(In reply to Frank Yan (:fryn) from comment #5)
> Chromium actually waits until a response is returned to show the
> remember-password prompt. This way, it can run its code to detect whether
> the login was successful and also avoid showing the prompt twice if the
> credentials were incorrect. We could use that interim hack in the short
> term, but I think Chromium's flow may be a better long term solution, even
> if it does delay the prompt a second or two.

I actually prefer this since Chromium's approach seems to deal better with redirects immediately following login. (Last time I logged into a new site, Firefox had hidden the doorhanger in the key icon in the address bar by the time I was sure I hadn't mistyped the password, which meant an extra click and some knowledge not everyone may have)
IMHO, we should make this a doorhanger, we should instead make it a tab-modal dialog just like what we are doing for alert() nowadays.
(Did you mean "shouldn't"?)
Erm, yes, I think we should not make this a doorhanger, as a tab-modal dialog in the style of what we do with alert() would fit this use-case better (it would show up in the content area but block only the tab that needs this auth - the concern there is of course spoofing, we need a good idea how to deal with that).
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #40)
> Erm, yes, I think we should not make this a doorhanger, as a tab-modal
> dialog in the style of what we do with alert() would fit this use-case
> better (it would show up in the content area but block only the tab that
> needs this auth - the concern there is of course spoofing, we need a good
> idea how to deal with that).

I rather like the rationale behind comment 9.

Tab modal is for site-provided stuff while things like doorhangers which extend beyond the viewport and interact with chrome are for browser-provided things like privacy-sensitive stuff and important permissions.

Am I forgetting any comments on why this wasn't good enough beyond "we don't currently have any kind of 'modal doorhanger' implementation"?
Using a doorhanger notification here doesn't make sense as a tab-modal prompt, because authentication is almost always required to access a page that triggers such a prompt, so the prompt should not be easily dismissable. Using a doorhanger notification makes it less obvious that an action needs to be performed.

The solution proposed in bug 613785 is better. Firefox for Windows 8 Metro will be implementing a solution similar to that one.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
why only firefox for windows?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: