Closed Bug 194821 Opened 19 years ago Closed 19 years ago

Page Info: add access key for _V_iew in Security tab


(Core :: DOM: UI Events & Focus Handling, defect)

Not set





(Reporter: bugzilla, Assigned: aaronlev)


(Blocks 1 open bug)


(Keywords: access)


(1 file, 2 obsolete files)

not sure if there's already a bug on this (bugzilla is being too slow to query
at the moment)... in Page Info, could we add the following access keys?

_H_elp button
_V_iew button in Security tab (only visible when viewing a secure page)

tested with 2003.02.24.04 comm trunk bits on linux rh7.2.
Adding dependency on bug 160694 - someone should decide whether the help button 
should be there or not first (lets do this within a sensible amount of time).
Depends on: 160694
Keywords: access
OS: Linux → All
Hardware: PC → All
There's also a bug asking for a close button, btw. I've never really cared much
whether there were buttons or not, but as I was telling spark on irc yesterday 
(before I was interrupted by my hard drive failing,) I think in the end the best
thing to do is simply to remove the help button (and not add a close button.)
We'd still want the key equivalents of these to work (esc, accel-w, and F1.)

On the other hand, it's slightly less work to just add an access key. I'll r=
either way, especially if you don't want to mix fixes for several bugs in one diff.
I think adding a close button is better. There are two reasons:
1.There are information about "Page Info" in the help docs. Click help, it will
display information for "Page Info".
2.It is consistent with other dialogs. Click Security tab, click View, in the
Certicate Viewer page, there are Help and Close buttons. 

So I made a patch to add Close button and accesskeys for Help and View.

I also change the Security tab's accesskey. Because I think S_e_curity is not a
good idea. And it removes the depedency with bug 143065.
Attached patch patch described in comment 3 (obsolete) — Splinter Review
Attachment #115624 - Flags: review?(db48x)
Jessie, this is _not_ consistant with other dialogs!!

Page info is a <window>, and windows should not have dialog buttons at the bottom.
The Certificate Viewer is a dialog, which should have buttons at the bottom.

The accesskeys for tab panels should be removed completely as discussed before.

We should use F1 for help, and Esc to close the window.
heh, just because it uses the <window> tag doesn't mean it's actually a window, 
there's a bug out there to switch it to <dialog> in order to reuse some of the 
machinery that it provides. That won't suddenly make it a dialog, it won't even 
change the way the window looks.

Still, I really prefer to remove the buttons, and make sure the standard keys 
work. A context menu item in the style of Windows' "What's This" has often 
helped people I've worked for, if you're feeling ambitious. I have a 
feeling "UI" people wouldn't like that, however. ;)

At any rate, that patch doesn't add the F1 key. It should add a <key> and a 
<command>, making both the button and the key have command="cmd_help" or 
whatever you call it.
actually, don't worry about <command>s, they're not used anywhere else in the 
window/dialog/thing. I need to finalize that patch that adds them to fix a Mac 
only bug.
So what was it you wanted me to change?
ok, the patch in the other bug is pretty good, it adds the F1 key and removes 
the button. Try the status bar thing Neil suggested. Feel up to adding a 
context menu?
The patch for bug 160694 is better than this. 

So I made another patch to remove the accesskeys on tabs and add _V_iew. Hope it
Attached patch patch as comment 10 (obsolete) — Splinter Review
Attachment #115624 - Attachment is obsolete: true
Attachment #115712 - Flags: review?(piersc)
Jessie, you're still adding a Close button. Remove that change, and the patch 
looks good.
Attached patch updated patchSplinter Review
Piers, I must be blind sometime. Now I remove that part. Please help me to
review it again. Thanks!
Attachment #115712 - Attachment is obsolete: true
Attachment #115814 - Flags: review?(piersc)
why are you removing the accesskeys from the tabs?
Daniel, the following is quoted from timeless,
"note that mozilla policy for the time being is not to place access keys on

there are also some discussions in bug 193265. After talking in irc, I decide to
move the accesskeys.

In fact, we do this by Ctrl+ tab.
Comment on attachment 115814 [details] [diff] [review]
updated patch

well, I suppose that's ok then. I suppose bug 194819 is meaningless then.
Attachment #115814 - Flags: review?(piersc) → review+
Comment on attachment 115814 [details] [diff] [review]
updated patch

Jag, could you sr= this patch as well? Thanks.
Attachment #115814 - Flags: superreview?(jaggernaut)
Comment on attachment 115814 [details] [diff] [review]
updated patch

Attachment #115814 - Flags: superreview?(jaggernaut) → superreview+
checked in Trunk!
Closed: 19 years ago
Resolution: --- → FIXED
Attachment #115712 - Flags: review?(piersc)
Attachment #115624 - Flags: review?(db48x)
a couple of observations when using today's (2003.03.03) trunk build:

a. there's still an access key for the _P_rivacy tab
b. Ctrl+Tab stops once i get to the Security tab (for non-secure pages)
--there's an old bug for this, does anyone remember it offhand?

other than that, all other access keys for tabs in Page Info have been removed,
and _V_iew works for secure pages. (and, nothing done for Help button due to bug
Summary: Page Info: add access keys for _H_elp button, and _V_iew in Security tab → Page Info: add access key for _V_iew in Security tab
a: the Privacy tab is added via code that has not been checked in to the tree,
see the p3p bug for that. (I still have some objections to it, btw)

b: I do not rember what bug it was, and I didn't find it just now. it'll come to
me later, I'm sure.
a. would that be bug 136238, or something else?
b. aha, it's bug 130644 and bug 175893.

anyhow, verifying this since other bugs cover my questions in comment 20.
the p3p bug is bug 177822

bug 136238 is weird since the Privacy tab doesn't exist in Mozilla, only in the
Netscape browser.
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.