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)
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.
Updated•23 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Comment 2•21 years ago
|
||
This bug still exists in 1.7b (build 2004031616). The "Examine Certificate..."
is selected even though "OK" shows as the default button.
Comment 3•21 years ago
|
||
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 → ---
Comment 4•19 years ago
|
||
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?
Assignee | ||
Comment 5•19 years ago
|
||
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 | ||
Updated•19 years ago
|
Assignee: nobody → kengert
Comment 6•19 years ago
|
||
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.
Updated•19 years ago
|
Target Milestone: --- → mozilla1.9alpha
Updated•18 years ago
|
QA Contact: junruh → ui
Comment 7•18 years ago
|
||
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].
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
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•