Closed Bug 125812 Opened 23 years ago Closed 16 years ago

Unknown Authority dialog defaults to View Certificate button

Categories

(Core Graveyard :: Security: UI, defect, P3)

1.0 Branch
x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla1.9alpha1

People

(Reporter: tpowellmoz, Assigned: KaiE)

References

()

Details

(Whiteboard: [kerh-coa])

Go to a URL that uses a certificate signed by an unknown authority. You'll see a dialog with the title "Website Certified by an Unknown Authority". The dialog is confusing because it appears to have both the view certificate and continue buttons selected. Based on the screen shots, that did not seem to be the intent when this dialog was reworked in bug 91466. The certificate signer/issuers should be listed in the dialog and the default button should be Continue. Adding the name of the signer seems to be point 2 in bug 101354. Note that the dialog is actually the 2nd one generated at the above URL. I'm using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020208.
Priority: -- → P3
Target Milestone: --- → Future
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
This bug still exists in 1.7b (build 2004031616). The "Examine Certificate..." is selected even though "OK" shows as the default button.
Mass change "Future" target milestone to "--" on bugs that now are assigned to nobody. Those targets reflected the prioritization of past PSM management. Many of these should be marked invalid or wontfix, I think.
Target Milestone: Future → ---
Product: PSM → Core
I just hit this bug with my company's corporate product. Basically, the "Examine Certificate" button has focus, when you might expect that focus to be on the OK button. The easy fix would be to use the onLoad function defined in chrome://pippki/content/newserver.js to place focus on the OK button. Would this be the "right" solution, though?
It seems, the current code does not try to set the default button, so we have the current situation by accident. However, one could argue, NOT having OK as default is a good thing! We might even want to make the "cancel" button the default. IMHO it's important the user can't access unauthenticated by just blindly clicking enter. This might need more thought.
Whiteboard: [kerh-coa]
Assignee: nobody → kengert
Well, typically Enter->OK, ESC->Cancel. So, unless you want to change the logic of the dialog (e.g., "Do not accept this certificate"), I think it should be consistent with what's normally expected. However, as long as I can use some type of single access key (_C_ontinue), that would be better than what's currently required.
Target Milestone: --- → mozilla1.9alpha
QA Contact: junruh → ui
The dialog has been reworked so the default is now cancel. This can be tested at https://www.debian-administration.org/ However, it now has a different focus problem. Now the radio buttons ( ) Accept this certificate permanently (*) Accept this certificate temporarily for this session have the focus instead of cancel. You can select OK with the keyboard only by [TAB][TAB or RARROW][RETURN].
Version: psm2.1 → 1.0 Branch
glad to see someone agrees w/ some of my points. w/ FF3 wXP i think we've deleted all these code paths. if i disable browser.xul.error_pages.enabled, i get fatal dialogs. As the bug was valid when filed, and someone did fix the original problem, I'm marking this as WFM. I would have done the same thing had comment 7 still applied, (proper resolution would be duplicate to whatever bug changed the behavior to match the description from comment 7). That OK/Continue was not a default action is a design choice (fixing a bug that was sorta described here).
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.