User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6 The HTTP password authentication dialog is modal. It should be the same kind of alert that occurs for blocked popups. Mozilla could take a leading role here - the horrible UI behind HTTP authentication is one of the reasons why authentication is done using HTML forms. Adding this and thereby allowing websites to take advantage of it will cause users to become used to entering passwords in the browser as opposed to the page. Furthermore, this will open up alternate authentication schemes in the same UI. (think SRP or something) Reproducible: Always Steps to Reproduce: 1. Surf to a website using HTTP basic or digest authentication. Actual Results: Wince in pain at the modal dialog. Expected Results: A non-modal popup for that tab only.

For that tab only ? Bug 123913

Not really a dup of bug 123913, IMO. Fixing that would be one possible solution, but I think it would be better to make the http auth UI a replacement page (similar to error pages) instead of a modal dialog.

I think Jesse is right. HTTP authentication should not open a modal dialog. When restoring a session with multiple tabs and one tab needs HTTP authentication, then the rendering of every other tab is blocked. A custom HTML or XUL ui similar to error pages - as suggested by Jesse - would be a good idea. There's also a need for a way to log out from such a session to prevent random guy sitting in front of the browser stealing information - why has one to exit Firefox to forget the password? (In reply to comment #3) > Not really a dup of bug 123913, IMO. Fixing that would be one possible > solution, but I think it would be better to make the http auth UI a replacement > page (similar to error pages) instead of a modal dialog.

You can log out using Tools - Clear Recent History - Active Logins. Not the most discoverable, but possible :) If we used a page instead of a dialog for logging in, it would be more natural to include instructions for logging out.

This isn't just an annoyance; it's a security problem. * The dialog is pretty much indistinguishable from an in-page spoof. * I'm blocked from seeing the URL bar (and it shows the previous page's URL). * I'm blocked from accessing Larry. * The only site-identity information I have is a non-human-parsable URL inside a sentence inside a paragraph. And sites get to add text to that paragraph!

Keeping the "dialog" appearance while making it actually be non-modal wouldn't really help, because users wouldn't know it's non-modal. So I'm morphing this bug slightly to be about changing it to an in-page thing. (Interestingly enough, Fennec is already going in this direction: bug 486693.)

There's more discussion on this in bug 244273, and bug 411085 "overhaul HTTP authentication prompting" appears closely related to this one, setting dependency accordingly.

Doesn't moving this to the content area make the "indistinguishable from an in-page spoof" problem even worse?

No, why would a page spoof its own authentication dialog? If we want to indicate that the authentication is hash-protected from certain MITM attacks, we can reflect analogously to how we indicate https.

No, the problem is ending up on an evil site, which present a page that looks identical to the browser's content-area promp for some other site.

I think users have a better shot at parsing the host/domain out of the address bar than they do out of a sentence. Especially once we fix the address bar to highlight the domain.

Adding Johnath as this touches security UI. Not sure about the right component, all unencrypted http auth prompts are handled by Mozilla's networking protocol code, while Security:UI component was usually used for protocol independent SSL UI.

Attaching a mockup of what such login page could look like. Note the Remember password checkbox is not necessary in it, because we could still display the top panel after the form has been submitted. It actually even makes more sense to do it then, because at that point the user knows for sure if the supplied credentials work or not. Similarly, if a fallback page link is present and the user clicks it, a similar top bar could be presented when showing it, which would allow the user to get the login form back if the 401 page is not what they wanted to see. :)

I'd rather not show the hostname in the content area. We want users to get used to looking at the address bar (and Larry), because anything in the content area can be spoofed. Likewise, we don't need to say "the site introduced itself as" and "if you trust this website".

(In reply to comment #17) > I'd rather not show the hostname in the content area. We want users to get > used to looking at the address bar (and Larry), because anything in the content > area can be spoofed. I don't mind that. Though I took the idea from the untrusted certificate prompt page. > Likewise, we don't need to say "the site introduced itself as" and "if you > trust this website". Don't mind that either. Regarding "the site introduced itself as" – I took bug 244273 comment #19 and #21 into account. I absolutely agree that the text could be refined in all labels. After all, my attachment is just a ten-minute mockup. I just want see this bug moving towards RESOLVED FIXED status. :)

Looking at the attachments of bug 244273, it looks like we currently have "The site says:". I just improvised a little.

So, what does this bug need to be solved?

(In reply to comment #20) > So, what does this bug need to be solved? Someone who does the work.

Since JS alerts are now tab-modal and do not block interacting with other tabs, maybe it's time to make Basic authentication behave the same way? In Opera it's already done, so maybe somebody in charge could put parity-opera flag. And would be good to work it out, cause now it looks like an anachronism.

Duping to bug 567804. If you think a doorhanger isn't the right UI then discuss it in that bug.