From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.8+) Gecko/20020131 BuildID: 2002013122 This is really a feature request. When I click on a link that (unknown to me) requires basic authentication, I'm presented with a dialog asking me for a username and password. At this point, I'm thinking, "Ooops, I don't have a username and/or password, I can't get this link." I then click "Cancel", which brings me to a "401 Authorization Required" page which tells me, "You don't have a username and/or password, you can't get this link." I already knew that. What I'd like is a third button on the authorization dialog which is, "Forget I ever clicked on this link, and don't bring me to a useless 401 page, just leave me on the current page". Of course, that seems hard to fit on a button, so I'm open to better names. :) Reproducible: Always Steps to Reproduce: 1.Click on any page using basic authentication
perhaps "OK" "Ignore" "Cancel" would be better. OK = send username and password Ignore = don't send a username and password Cancel = send me back to the page from whence i came at any rate, this is probably not going to make it within the moz 1.0 timeframe. -> future
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P5
Target Milestone: --- → Future
Why even have an Ignore button if all that does it take you to a 401 page? IMO, the behaviour should be OK = send username and password Cancel = send me back to the page from whence i came
i thought about that, but it's possible that the 401 page could have information for a user that doesn't remember their password, for example. in other words, a website could expect the user to see the 401 page for whatever reason.
*** Bug 146494 has been marked as a duplicate of this bug. ***
As the admin of a site where the 401 page is a form that the user can fill out to get a new password, we should show the 401 page... ;)
Whatever the number and labels of buttons, "Cancel" should cancel, not go forward, anywhere. >:|
It's *not* going "forward", though. It's already loaded the 401 page along with all of its content. It's just delaying the display of this content pending your response to the authentication dialog. If you click Cancel, it shrugs and displays what it has. If you click OK, it discards the 401 response's content and tries again with the authentication credentials you provided. So really, it *is* cancelling. It's cancelling the retry-with-authentication request that it's about to try and do. I almost prefer the three-button option, but I can't think of some good sensical labels that would make that arrangement sensical to the casual user. Lacking that, the current behavior makes the most sense (especially where the 401 content is valuable).
*** Bug 190919 has been marked as a duplicate of this bug. ***
to comment #5: This use is somewhat misleading, since a user wants to see that form only if he really forgot his password, which he usually recognizes after clicking submit, not cancel. A user clicking cancel really does not want to see any action afterwards (except a disappearing password dialog...). Or in a another view, what's the difference between the buttons now ? Functionally, nearly nothing. So I would vote to really implement what a user expects from the buttons, regardless of what's happening behind the curtains. If you prefer the three button solution, it's ok from my view.
> Or in a another view, what's the difference between the buttons now ? If you click "OK" with the wrong password you get the same dialog back again as the site responds with a 401. This is the only acceptable course of action on "OK". Given that, if the user is to ever see the error page another button needs to be clicked. Currently, that would be "cancel".
If we are going to muck with this, all buttons have to make more sense. Maybe: [send|login] [quit] [back] ? I don't think we can change the individual meanings of the current buttons, that would break compatability. I don't think we should just add one more button, because the real problem is the current buttons don't make enough sense.
QA Contact: tever → httpqa
Summary: Ability to "back out" of basic auth → "back out" of basic auth without displaying 401 error page
Looks good, esp. 'back' is a very clear description of the intended action.
I might advise against the use of "Login" for the button's label. To "log in" implies the creation of a session, when that isn't necessarily the case. The user is simply authenticating for this specific request. Subsequent requests may not require authentication, nor is there always a session the user must "log out" of. Perhaps: [ OK ] [ Ignore ] [ Abort ] Or: [ OK ] [ Do Not Authenticate ] [ Cancel ] The first attempts to authenticate, the second dismisses the dialog and displays the 401 response, and the third aborts the "logical" request entirely, reverting to the page the user just visited. I wouldn't worry too much about the labels of the buttons breaking "compatibility". It's just UI. If someone hits Cancel expecting the old Cancel behavior, no harm is done. They can repeat the request and pay more attention this time without breaking anything.
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Target Milestone: Future → ---
showing the 401, with information, is the right thing.. and http auth is pretty infrequently used these days anyhow
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.