Closed Bug 163007 Opened 22 years ago Closed 20 years ago

bugzilla accesskeys conflict with browser accesskeys

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 2.18

People

(Reporter: jruderman, Assigned: gerv)

References

(
URL
)

Details

(Keywords: access)

Attachments

(1 file)

Patch v.1
2.30 KB, patch
justdave
: review+
goobix
: review+
Details | Diff | Splinter Review 
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.
Blocks: 159199
Keywords: access
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
nobody@bugzilla.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. ***
OS: Windows XP → All
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
Closed: 22 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".
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.
> We should go in a new direction for Windows and Linux and choose Alt+Shift for
> the default accesskey modifier setting.

Aaron: as you know, that's under the control of the browser, not us (unless we
reimplement accesskeys in JavaScript using event capture).

I think the immediate thing for Bugzilla to do here is to remove the
particularly annoying ones for the 2.18 release.

Gerv
Attached patch Patch v.1 — — Splinter Review 
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)
Flags: blocking2.20?
Flags: blocking2.18?
Whiteboard: patch awaiting review
Attachment #168666 - Flags: review+
Flags: approval?
Flags: approval2.18?
Attachment #168666 - Flags: review?(justdave) → review+
Flags: blocking2.20?
Flags: blocking2.20+
Flags: blocking2.18?
Flags: blocking2.18+
Flags: approval?
Flags: approval2.18?
Flags: approval2.18+
Flags: approval+
Target Milestone: --- → Bugzilla 2.18
Whiteboard: patch awaiting review → patch awaiting checkin
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: 1.40.2.4; previous revision: 1.40.2.3
done

Gerv
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → FIXED
Whiteboard: patch awaiting checkin
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).
Blocks: 313454
Simon: that was my mistake. See bug 313728.

Gerv
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: