Closed Bug 411085 Opened 17 years ago Closed 4 years ago

overhaul HTTP authentication prompting

Categories

(Firefox :: Security, enhancement)

Product:
Firefox
Component:
Security
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 613785
Milestone:
Future

People

(Reporter: Dolske, Unassigned)

References

(Depends on 4 open bugs)

Details

Attachments

(1 file)

Prompt per tab is needed, Opera example in image.
(deleted), image/png
Details
+++ This bug was initially created as a clone of Bug #244273 +++ There are a number of interesting ideas for how how prompting for authentication could be changed from our current scheme (based on modal dialogs). See bug 244273 comments 16, 19, 20, 21 for some initial ideas.
No longer depends on: CVE-2008-0367
Assignee: dveditz → kengert
Component: Security → Security: UI
QA Contact: toolkit → ui
Depends on: 399583
Depends on: 516781
Depends on: 567804
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18pre) Gecko/20110423 Namoroka/3.6.13pre Firefox.3.6 ( .NET CLR 3.5.30729; .NET4.0E) - Build ID: 20110423033212 In Namoroka the "Authentication Required" Dialog is badly broken. Namoroka pops up this Dialog for ftp Sites in your PAST History ("past" meaning you visit there and then press the [Back] Button. You are no longer visiting there and would either need to press the [Forward] Button or re-enter the URL). The Dialog is VERY DIFFICULT to deal with. Ex. 1: If you press the (red) [X] then the loading of Namoroka HANGS. The ONLY way to restore functionality is to right-click in WinXP's Toolbar on the 'Namoroka Icon' (which pops up a Toolbar Menu) and then left-click on a BLANK area of the Toolbar to close the Toolbar's Menu (without making a Selection); then Namoroka will operate (poorly) again. Ex: 2: If you enter no name and password and hit [OK] OR hit [Cancel] then it takes a VERY long time to register this action and the Dialog Box will popup again. When the Dialog Box is present loading of ALL Tabs is halting and the 'spinner' just spins. Ex. 3: Sometime the "Authentication Required" Dialog Box won't accept mouse-clicks so you need to TAB to choose [Cancel] and then hit SpaceBar to select [Cancel]. Ex. 4: As noted above it snoops into your PAST History and expects a Password for an URL you are NOT visiting. The is most unfair since: * Then you need to employ the above tricks to try to get your Tabs to load. * Then you need to click the [Down-Arrow] (between the [Back] and [Forward] Icons) AND then use your [Up] and [Down] Keys (on the Keyboard) to scroll through the History of EVERY Tab to attempt to locate the URL in the Status Bar (at the bottom of the Window) so you can figure out which Tab to close; since you can't just erase a single History Entry. Ex. 5: Multiple "ftp'ed History Tabs" cause multiple "Authentication Required" Dialogs to popup (all overlapping so you only see one at a time, if you are restarting and reloading hundreds of Tabs the "Authentication Required" Dialogs cause such a slowdown that it is difficult to click on the "Authentication Required" Dialog's Chrome and move it (so you can see if there are any underneath it)). It would be SO much better to give us a "Problem Loading Page" /!\ Icon (on the Tab) and a Blank Page - require us to reload and THEN give us the Dialog. Then the "Authentication Required" Dialog would not slow other Tabs from loading AND we MIGHT even know which Dialog was for where. There is the Site's Name in the Dialog but not the Full URL (without the Directory how do we know the Password unless it is either Site-wide OR we use the same Password for everything). Which entry in the History does the Request pertain to, we might visit different directories with different Passwords. Since we are restarting after a CRASH can't we assume that the Password is the same as it was a moment ago. When _this_ Page is reopened I am still Signed on (as is done for most (but not all) Sites, when we crash and restart we might not walk away from the Keyboard (were it not for the frustration) so why require the "Authentication Required" Dialog (and worse one so broken). :RANT:
The "Authentication Required" Dialog also pops up if you load a Page that has an Image on it that has "ftp://" in it's URL. (Trivial) example html (actual Page where error occurs is much longer): <html> <body> <img src="ftp://ftp.xxx.com/images/image.png"> </body> </html> This is WRONG since you would never would have had to (nor could you) have entered a User name and Password for the Site and thus after a restart you should not be required to do so by Namoroka. This particular Page worked fine up until a few hours ago. Prior to Namoroka's Update 3.6.18pre 2011042403333 (10 minutes ago) it was also broken. This breakage occurred (or was noticed) sometime after 2:00 am today (and not caused by '2011042403333'). Yesterday it was working fine.
Going to a different URL (in History) and then coming back, by clicking through the Link, reloads the Page and there is no "Authentication Required" Dialog; the Image appears normally. That PROVES that the Bug is in Namoroka and that the Dialog is being requested for something that is not only impossible but is also not required. This is the URL (search for "04/03/2011 09:26 AM" to find the Post, it's the second Image): http://forums.amd.com/forum/messageview.cfm?catid=12&threadid=146923&STARTPAGE=2&FTVAR_FORUMVIEWTMP=Linear Thanks, Rob
Rob, thanks for your observations! However, I suggest that you report them as a separate bug (if that is not reported yet), because the scope of your problem is absolutely different to what is being solved here (UI issue). :) Cheers!
(In reply to comment #8) > Rob, > > thanks for your observations! However, I suggest that you report them as a > separate bug (if that is not reported yet), because the scope of your problem > is absolutely different to what is being solved here (UI issue). :) > > Cheers! I did report it as Bug 620582 and we decided it would fall under this (Bug 411085) "Umbrella Bug". My newer observations are, as you characterize it, a "UI Issue" to the extent that I have given an explanation as to why the "UI" is being called when it ought not to have been. I have also noted the breakage in the UI and how it fails to operate as expected when it is called.
(In reply to comment #9) > I did report it as Bug 620582 and we decided it would fall under this (Bug > 411085) "Umbrella Bug". My newer observations are, as you characterize it, a > "UI Issue" to the extent that I have given an explanation as to why the "UI" is > being called when it ought not to have been. I have also noted the breakage in > the UI and how it fails to operate as expected when it is called. I didn't make myself clear enough when submitting that comment, sorry. I meant that this bug is (or at least to me it seems to be) more about general decisions on UI/UX design direction to take, meanwhile your observations are about actual bugs in that UI/UX that should be fixed. I haven't played with Namoroka yet, but if it uses the doorhanger for HTTP/FTP auth, then I would guess that maybe your bug is blocking bug 567804 (or some other bug, which actually introduced that part of code), instead of being a duplicate of this one.
reassign bug owner. mass-update-kaie-20120918
Assignee: kaie → nobody
Nom'ing Bug 333521 to be tracked by this meta bug.
(In reply to Florian Bender from comment #12) > Nom'ing Bug 333521 to be tracked by this meta bug. … and probably Bug 538719 and Bug 647010.
This seems more like a front-end tracking issue (to be sure, there will be PSM changes required by this, but those can be individual bugs filed in PSM).
Component: Security: UI → Untriaged
Product: Core → Firefox
Component: Untriaged → Security: PSM
Product: Firefox → Core
PSM isn't the right place for this bug.
Component: Security: PSM → Security
Product: Core → Firefox

I'm going to dupe this with Bug 613785 where we switched to tab level dialogs for HTTP auth since it seems to fit the intent. Feel free to re-open if you think that's incorrect!

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: