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
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.
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 works.
Created attachment 115712 [details] [diff] [review] patch as comment 10
Attachment #115624 - Attachment is obsolete: true
Jessie, you're still adding a Close button. Remove that change, and the patch looks good.
Created attachment 115814 [details] [diff] [review] updated patch 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
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 tabs." 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 sr=jag
Attachment #115814 - Flags: superreview?(jaggernaut) → superreview+
checked in Trunk!
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
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 160694.)
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.
Status: RESOLVED → VERIFIED
the p3p bug is bug 177822 bug 136238 is weird since the Privacy tab doesn't exist in Mozilla, only in the Netscape browser.
You need to log in before you can comment on or make changes to this bug.