User-Agent: Mozilla/5.0 (X11; U; Linux i686; da; rv:220.127.116.11) Gecko/20070718 Fedora/18.104.22.168-4.fc6 Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; da; rv:126.96.36.199) Gecko/20070718 Fedora/188.8.131.52-4.fc6 Firefox/184.108.40.206 When I try to open a page with a apache .httpaccess file and press cancel, I get to a "Authorization Required" error page, instead of staying where I am. Reproducible: Always Steps to Reproduce: 1. Go to a page with a apache .httpaccess file 2. When asked for password press cancel Actual Results: A "Authorization Required" error page Expected Results: Returning to where I were
You mean .htaccess I think.
Yes indeed :)
This is a mass search for bugs that are in the Firefox General component, are UNCO, and have not been changed for 1000 days and have an unspecified version. Reporter, can you please update to Firefox 3.6.10, create a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you still see the bug, please update this bug. If the issue is gone, please set the resolution to RESOLVED > WORKSFORME.
No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
No reply, INCOMPLETE. Please retest with Firefox 3.6.13 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
It's still there.
Tyler, he can of course see the behavior... I'm not sure what the point of asking every two months is. Thomas, you seem to be confused about how HTTP authentication works. The order of the steps is this: 1) We send the request. 2) The server responds with a 401 error response. This response has a response body; this is the body that should be displayed if the user can't provide authentication information. Here's the relevant HTTP spec text for the 4xx response codes: Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user. In fact, for 401 in particular it also says: If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. In other words, we SHOULD (spec term there) show the error page even if you just type the password wrong, but show the authentication popup anyway... We don't do that, since that's not really useful to most users. But showing the error page the server sent when the user gives up on the authentication is in fact helpful, in many cases. If your particular server happens to send a useless error page, that seems like a problem with the server.
I see your point about the 401 response body, and I know this is how most browsers work. I do however think "Cancel" is the wrong word to use. This is because "Cancel" in all HIG's mean "Oops, I didn't want to do that, leave me with what I had". I know the user technically "came" from the error page, but since the user has no idea of that, "Cancel" is still the wrong word to use. Perhaps it could be changed to something more indicative of the meaning "I don't have a code, please tell me more". From the Windows HIG: Clicking Cancel means abandon all changes, cancel the task, close the window, and return the environment to its previous state, leaving no side effect. From the Gnome HIG: This [Cancel] provides an escape route for users to stop an action in response to new information, or just if they clicked accidentally. Clicking the Cancel button reverts the application to its state prior to the user action.
I agree that giving that button a saner label is a good idea. Worth filing a separate bug on that...