I think these are the worst conflicts (from bug 159199 and bug 102648): Access+D: Focus address bar in IE and soon in Mozilla (bug 157669). Access+B: Bookmarks in mozilla. Individual bookmarks don't have accel combos, so this is an important menu access key. Access+A: Favorites in IE. mpt said in bug 102648 comment 12 that dealing with conflicts is the job of the browser and not the web app because of localization, but I disagree.
CCing Aaron for his thoughts. My approach to this was to provide accesskeys for everything, although I avoided F, for File. It all worked out rather nicely - most things use their initial letter. Rejigging it all would be somewhat complicated. Perhaps we should instead fix the bug that lets us do what IE does: pressing Alt-B tries the page first, but Alt <release Alt> B gives you the menu. Gerv
Gerv, I would avoid using our menu accesskeys - I think that was smart. I would also avoid some of the ones used in IE, in case someone uses Bugzilla with IE. And I would definitely avoid D, because IE uses that to zip to the address bar, and we may copy that at some point. BTW, you don't *have* to use a letter in the prompt, you can use a letter or number in parenthesis after the prompt, for example: Keywords (_1_) -- the user presses alt+1 to get there. Also, note that I have submitted a patch for review on bug 68841, which underlines accesskeys in HTML (as well as on XUL checkboxes and radios).
> Gerv, I would avoid using our menu accesskeys - I think that was smart. I haven't avoided them all. > I would also avoid some of the ones used in IE, in case someone uses Bugzilla > with IE. And I would definitely avoid D, because IE uses that to zip to the > address bar, and we may copy that at some point. The problem is that then you a) run out of letters and b) have to use non-initial letters. > BTW, you don't *have* to use a letter in the prompt, you can use a letter or > number in parenthesis after the prompt, for example: > Keywords (_1_) -- the user presses alt+1 to get there. Yeah, but that is _horribly_ ugly. > Also, note that I have submitted a patch for review on bug 68841, which > underlines accesskeys in HTML (as well as on XUL checkboxes and radios). What does it do if the accesskey is already underlined, as it has to be for compatibility with IE? I seem to remember it then double-underlines. I'm not convinced that this is ideal, because then in Moz you'd see a double underline under just that letter. Is there any way of checking if the _word_, as opposed to the letter, is underlined, and only double-underlining if that is the case? Gerv
It won't double underline, but if the accesskey is in a link, it will boldface the letter. I don't think it's ugly to put (_1_), etc. after prompts, especially if it still lets people access their main menus easily, which I think would be nice. Otherwise, you'll just get a lot of questions about it - it won't be fun. "How come I can't type Alt+F?" "Well you can, you have to press Alt, then let go, then press F". "Oh, that sucks"
The alt-release-f thing is a windows-ism, isn't it? ISTR that dating back to win3.1, where alt-release took focus to what was the minimise-menu thingy (no, I don't know the proper name for it), and then you could use the arrow keys to move left/right to the deisred menu, then down to the required option. IOW, fixing that wouldn't help on non-windows. Alt-[1-9] is used on unix for the various apps in the windows menu, so you can't use numbers for bz accesskeys without conflicting (unless you mean to use ctrl-[1-9] instead...)
>Alt-[1-9] is used on unix for the various apps in the windows menu, that's ctrl+[1-9] for me on linux
hmm. It is too. I was sure that I checked before writing that last comment. Oh well...
This is always going to be a balance - we can't avoid every menu in every web browser. So, if someone lists the menus and accesskeys for IE 6 windows, IE 5 Mac and Opera 6 here (as the key players), with capital letters indicating accesskeys, we can see what's commonly in use. Then, we can see what trade-offs it's worth making. Mozilla 1.1b Linux: File, Edit, View, Go, Bookmarks, Tools, Window, Help, (Debug, Qa) Netscape 4.7 Linux: File, Edit, View, Go, Communicator (but no menu accesskeys) Gerv
*** Bug 164139 has been marked as a duplicate of this bug. ***
I am assigning all the bugs I am not working on in the immediate future to firstname.lastname@example.org. This means: - I will be able to search for bugs assigned to me as a list of bugs I'm going to fix (which is as it should be), and - people won't falsely assume I might be about to fix a bug when I'm not. Gerv
Assignee: gerv → nobody
*** Bug 183861 has been marked as a duplicate of this bug. ***
I agree, this is the job of the web browser to resolve conflicts with accesskeys. This exact situation is one of the reasons I initially argued against accesskeys in Bugzilla because there was no way to prevent conflicts. I was assured that most browsers use a different metakey for the HTML accesskeys than they do for the browser accesskeys, and that was the only reason I agreed to allow it to be implemented. Obviously that's not the case. So we have two choices here: 1) Evangelism to the affected browsers to get them to fix their accesskey implementation 2) Stop using accesskeys because the concept is obviously flawed if the specification allows conflicts with browser and OS accesskeys.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
Or 3) use a pref. Many people do not care about using accesskeys (I'd say the majority, but again, what do I know?) and they could have the pref off. Others do use them and want them on. In any case, why is this bug marked resolved if we need to decide still which of the options Bugzilla will be taking? I see no real resolution here...
yeah, you're right. reopening.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
You could also have accesskeys with an underlined number and just put it in parens. For example: Bug 163007 depends on (_1_): That way there's a quick shortcut but no conflict.
aaron: that's just dodging the issue. Letter accesskeys are very useful; if there's a usability problem because the way we implement them in Mozilla conflicts with menu access keys, then we need to fix that for all applications, rather than say "Well, just don't use letters, then." (That's aside from the fact that there are far more controls on a Bugzilla page than digits.) Doesn't IE use "sticky alt" to resolve this problem? I'm sure we have a bug open on that. Gerv
Sticky alt menu access fixes the problem for everything except for the location bar accesskey, which is Alt+D in English. So, there isn't really that much of a problem, except that most people don't know about it. We're like IE here.
So both IE and Moz use Alt as the accesskey modifier, even though it clashes with menus. So, Moz is faced with the choice of either picking another one (Ctrl-Shift or something bucky like that) or just doing what IE does. We could add an accessibility pref (yes, I know, hear me out) of "Menu access always overrides web page accesskeys" or something similar. This would probably be set by distributors rather than end-users. Gerv
*** Bug 232622 has been marked as a duplicate of this bug. ***
*** Bug 236126 has been marked as a duplicate of this bug. ***
*** Bug 248985 has been marked as a duplicate of this bug. ***
This bug is driving me batty. I'm a heavy keyboard user and the accesskey attributes in Bugzilla are continuously getting in my way. Does _anyone_ actually use them? As far as I'm concerned they are a severe accessibility problem. Every time I try to use a menu, focus instead moves to a random field on the form. Can we _please_ drop this "feature" as soon as possible? Note that "accesskey" is currently deprecated in the the Web Apps proposed draft: http://whatwg.org/specs/web-apps/current-work/#keyboard
Unused Access Keys ------------------ (Upper case free in all, Lower case used in Opera only) C I J K L m n O p R S X Y Z Preexisting Access Keys ----------------------- A ie6 B m1.5 o7 D ie6 m1.4 E ie6 m1.5 o7 F ie6 m1.5 o7 G m1.5 H ie6 m1.5 o7 M o7 N o7 P o7 Q m1.5 T ie6 m1.5 U m1.5 V ie6 m1.5 o7 W m1.5 o7 Keys used in m1.5 are also used m1.4. Opera 7 doesn't have keyboard navigation.
Hixie: are there particular keys on particular pages which you keep hitting? Perhaps we went a bit overboard; perhaps some (like focussing Additional Comments) are more useful than others. Gerv
they're all annoying. either provide a pref that users can use to enable access keys for bugzilla, or remove the feature entirely.
> they're all annoying. If your browser normally does precisely nothing when you press Alt-Z, then it's unlikely to be annoying if the web page binds it to do something useful. Gerv
The keys that give me trouble are on the bug entry page and the query page, primarily Alt+T, Alt+E, and Alt+V (the Tools, Edit and View menus in Firefox). I also sometimes hit Alt+D (the address bar), and end up entering random URIs in to the "depends on" box, which is a bit confusing. :-)
Severity: major → enhancement
Alt+D has actually caused me to enter a few stray dependencies when I, for example, press Alt+D, type "cnn", and hit Ctrl+Enter before I realize what's happened. It just turns out there's a bug with an alias of "cnn".
see comment 12 :)
Access keys are also going to cause headaches when we let admins change the field names in field-descs.none.tmpl and have it take effect everywhere.
I find myself hitting Alt+D to focus the address bar a lot; this is the only one that catches me.
I must say that I actually never run into conflicts with the access keys on the Mac, because the browser access keys on the Mac all use the command key, and the content access keys use the control key. Why other platforms couldn't have figured out something similar... ;)
Hardware: PC → All
We could keep content/UI accesskeys separate on Windows and Linux: We should go in a new direction for Windows and Linux and choose Alt+Shift for the default accesskey modifier setting. It doesn't conflict with anything in the browser. People will be free to use the accesskeys in Mozilla and the page without worrying about the conflicts. Alt+shift is not used anywhere in Mozilla so far, I've made sure of that because Mac uses Alt+shift for entering extended characters. However there is no conflict on Win/Lin because Mac will continue to use Control for accesskeys. It's not like we can effectively use Alt+Shift for anything else, since those keys are not available on the Mac platform For people who complain that this breaks platform compatibility, I'd be open to discussing the idea of having plain alt accesskeys still work when the UI doesn't need them. In other words, the UI could get first grab at alt accesskeys for its mnemonics, as opposed to the situation now which causes this bugzilla problem. Alt+Shift would guarantee to be for content access. On the down side I think this is a slightly harder rule for users to understand.
Aaron, because I was the one raising the stink over in the other bug, let me just summarize by saying that I would be fine with this approach.
Created attachment 168666 [details] [diff] [review] Patch v.1 This patch removes the four accesskeys mentioned in comment 27 and comment 28. It leaves accesskey="" in the source; this appears to have no detrimental effect on Mozilla. If it would cause problems in other browsers (Hixie?) a more extensive patch could eliminate it. Gerv
Assignee: nobody → gerv
Status: REOPENED → ASSIGNED
Attachment #168666 - Flags: review?(justdave)
Attachment #168666 - Flags: review?(justdave) → review+
Target Milestone: --- → Bugzilla 2.18
Fixed on trunk and branch. Checking in template/en/default/bug/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.46; previous revision: 1.45 done Checking in template/en/default/bug/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v <-- edit.html.tmpl new revision: 220.127.116.11; previous revision: 18.104.22.168 done Gerv
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago → 14 years ago
Resolution: --- → FIXED
Too bad this got fixed after the recent bmo upgrade....
I believe Dave/Myk plan to upgrade again soon... Gerv
*** Bug 303593 has been marked as a duplicate of this bug. ***
Is it intentional that this patch hasn't made it into 2.20 after all? Bug 215148 added the accesskeys back without mentioning why (see file revision 1.59). Should it be intentional, please indicate where this decision has been made and mark this bug as wontfix. Otherwise please reopen this bug and wait for an updated patch (or file a new bug for the regression).
Simon: that was my mistake. See bug 313728. Gerv
You need to log in before you can comment on or make changes to this bug.