Last Comment Bug 129179 - (accesskey) Meta bug: hook up XUL accesskeys throughout the UI
: Meta bug: hook up XUL accesskeys throughout the UI
Status: NEW
: access, helpwanted, meta
Product: Core
Classification: Components
Component: Keyboard: Navigation (show other bugs)
: Trunk
: x86 Windows 2000
P2 enhancement with 2 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on: 90318 237273 258466 303634 24873 40759 40761 62703 64457 68243 68337 68341 68841 68961 78153 78261 110117 111031 112732 113946 114071 114464 114465 121680 129213 130650 131672 133155 134066 135567 143065 146825 175271 176359 183167 183182 190331 191160 191471 193068 193271 194819 194821 194858 195784 195794 221783 229707 258437 258508 277296 322237 322239 322240 322241 322242 322243 322245 322246 322247 322248 322249 327748 371845 387015 398603 398699 398700 398704 398706
Blocks: patchmaker aix-access
  Show dependency treegraph
Reported: 2002-03-05 17:02 PST by Aaron Leventhal
Modified: 2013-04-27 04:39 PDT (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Aaron Leventhal 2002-03-05 17:02:11 PST
Now that bug 959 is fixed, we can use XUL accesskey.
An accesskey is an underlined letter in a form control that gives a keyboard
shortcut for activating the control. The accesskey FAQ and guidelines document
is at

Unfortunately, all is not perfect. Crucial bugs that still need to be fixed:
Bug 128608 - Accesskeys don't work for (xul) tabpanels
Bug 68841 - We don't underline accesskeys for checkboxes or radiobuttons (they
work, but aren't displayed correctly)

However, we have enough to now start hooking these up.
Comment 1 User image Aaron Leventhal 2002-03-05 17:06:29 PST
Just to reiterate. It's important for anyone working on these bugs to read  the FAQ:
Comment 2 User image Dean Tessman 2002-03-05 18:07:11 PST
I'd like to get bug 128987 fixed before we get too far into these.  The fewer
things that reference .accessKey, the fewer things that fix needs to change.
Comment 3 User image Dean Tessman 2002-03-05 21:31:51 PST
Err.... forget I said that.  128987 is wontfix.
Comment 4 User image Olga 2002-03-06 10:54:06 PST
Thanks, Aaron for pointing to this document in comment 1. 
I am going to review other existing bugs regarding mnemonics and make this one
dependent on them. As you suggested, I change component to Keyboard Navigation,
but Product: MailNews. 
Comment 5 User image Aaron Leventhal 2002-03-06 11:40:42 PST
The first thing we need is for someone to file the rest of the bugs for this -
probably one per dialog is a good idea.
Comment 6 User image Olga 2002-03-06 12:04:07 PST
I have a bunch of them for MailNews. They are going to appear here in 'Depends
on' area.
Comment 7 User image Olga 2002-03-06 12:32:32 PST
For MailNews product there is no 'Keyboard Navigation' component. It is only for
Browser. So, looks like that MailNews bugs won't have suggested component. But I
list them here.
Comment 8 User image Dean Tessman 2002-03-06 12:34:27 PST
Quick note on something I found when fixing bug 78153.  If you're trying to set
or change the accesskey from js, use .accessKey not .accesskey.
Comment 9 User image Aaron Leventhal 2002-03-09 20:59:40 PST
Preferences accesskey people should be aware of bug 129808 - Pref panel
accesskeys don't work when category tree or dialog button has focus.
Comment 10 User image Olga 2002-07-11 14:02:50 PDT
There is meta bug 154249 only for Mail front end and accessibility issues -
other than mnemonics. 
Comment 11 User image David Bolter [:davidb] 2009-06-16 11:24:19 PDT
Mass un-assigning bugs assigned to Aaron.
Comment 12 User image Tantek Çelik 2012-07-22 15:01:37 PDT
The URL provided in the bug description ( was 404 so I removed it.

Also, it seems a recent update (FF14? FF14.0.1?) broke accesskey on Mac.

Expected: ctrl-accesskey works. e.g. on any MediaWiki site like Wikipedia, etc.:
* ctrl-e to edit, then
* ctrl-p to preview
* or ctrl-s
all regardless of focus-state (which element on the page is focused etc.)

Actual behavior in FF14.01/MacOSX Lion: ctrl-option-accesskey *sometimes* works, e.g. on any MediaWiki site like Wikipedia, etc. 
* control-accesskey combinations noted above FAIL (do nothing).
* ctrl-option-e to edit
* ctrl-option-p to preview FAILS regardless of what element is focused.
* ctrl-option-s to save FAILS. If you click somewhere on the page to unfocus/defocus a text field which might be active (e.g. the textarea), then this works. Such unfocusing should not be necessary either.

There may be multiple regressions occurring here. Noting all this in this bug because this is the *only* result when you search Bugzilla for "accesskey" (no list of results, just directly takes you to this bug).

Note You need to log in before you can comment on or make changes to this bug.