Closed Bug 408572 Opened 17 years ago Closed 14 years ago

Don't send request when cancled in password dialog

Categories

(Core :: General, defect)

defect
Not set
minor

Tracking

()

RESOLVED INVALID

People

(Reporter: thomas, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; da; rv:1.8.0.12) Gecko/20070718 Fedora/1.5.0.12-4.fc6 Firefox/1.5.0.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; da; rv:1.8.0.12) Gecko/20070718 Fedora/1.5.0.12-4.fc6 Firefox/1.5.0.12

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.
Whiteboard: [CLOSEME 2010-11-01]
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.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Still there.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
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.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → INCOMPLETE
It's still there.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Whiteboard: [CLOSEME 2010-11-01]
Version: unspecified → 3.6 Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Version: 3.6 Branch → Trunk
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.
Status: NEW → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → INVALID
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...
You need to log in before you can comment on or make changes to this bug.