Last Comment Bug 357101 - (numaccesskey) SHIFT relevant for accesskeys / non-alphabetic accesskeys potentially broken (AKA ALT+SHIFT+number not working)
(numaccesskey)
: SHIFT relevant for accesskeys / non-alphabetic accesskeys potentially broken ...
Status: RESOLVED FIXED
: access, regression
Product: Core
Classification: Components
Component: Keyboard: Navigation (show other bugs)
: Trunk
: All All
: -- major with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
: 357317 359383 359976 (view as bug list)
Depends on: 351310
Blocks: 340902
  Show dependency treegraph
 
Reported: 2006-10-18 04:29 PDT by Lothar
Modified: 2006-12-20 15:55 PST (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Very simple testcase for numbered accesskeys (168 bytes, text/html)
2006-10-18 04:41 PDT, Lothar
no flags Details
work-around extension (1.49 KB, application/x-xpinstall)
2006-10-24 05:54 PDT, Simon Bünzli
no flags Details
work-around extension (version 2) (2.99 KB, application/x-xpinstall)
2006-10-25 13:21 PDT, Simon Bünzli
no flags Details

Description Lothar 2006-10-18 04:29:08 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1) Gecko/20061017 BonEcho/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1) Gecko/20061017 BonEcho/2.0

A link or button with a numbered accesskey doesn't work at web pages.
HTML Example:
   <a href="http://wiki.splitbrain.org/wiki:quickbuttons" accesskey="1">DokuWiki Editing-Toolbar</a>
The link would only open if the accesskey is a letter, e.g. accesskey="t" not a number.

Numbers are used at the editor of DokuWiki for headings: 1 for a H1, 2 for a H2...
Sorry if it's already addressed, I couldn't find anything similar during my searches.

Reproducible: Always

Steps to Reproduce:
1. Generate/visit a web site with numbered accesskeys
2. Press accesskey combination ALT+SHIFT+number

Actual Results:  
Nothing happens.

Expected Results:  
Opens Link or pushes the corresponding button.

No problems with numbered accesskeys at FF1.5.
Comment 1 alexander :surkov 2006-10-18 04:32:35 PDT
(In reply to comment #0)

> Steps to Reproduce:
> 1. Generate/visit a web site with numbered accesskeys
> 2. Press accesskey combination ALT+SHIFT+number

Can you get URL of web site or attach testcase?
Comment 2 Lothar 2006-10-18 04:41:14 PDT
Created attachment 242622 [details]
Very simple testcase for numbered accesskeys
Comment 3 Lothar 2006-10-18 04:44:00 PDT
For testing you could also visit http://wiki.splitbrain.org/playground:playground , edit the page and try to add a heading with accesskey alt+shift+1 for a H1. Used accesskeys are listed at http://wiki.splitbrain.org/wiki:quickbuttons
Comment 4 alexander :surkov 2006-10-18 04:53:36 PDT
(In reply to comment #2)
> Created an attachment (id=242622) [edit]
> Very simple testcase for numbered accesskeys
> 

Works fine on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061017 SeaMonkey/1.5a.
Comment 5 Lothar 2006-10-18 05:21:59 PDT
(In reply to comment #4)
> (In reply to comment #2)
> > Created an attachment (id=242622) [edit]
> > Very simple testcase for numbered accesskeys
> > 
> 
> Works fine on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
> Gecko/20061017 SeaMonkey/1.5a.

I found the problem with the Win version of
 - FF2 nightly build ("Gecko/20061017 BonEcho/2.0")
 - FF2 RC3 ("Gecko/20061010 Firefox/2.0") and 
 - FF2 RC3 in safe-mode.
Comment 6 Simon Bünzli 2006-10-18 07:57:03 PDT
Regression from bug 340902. One suggestion for how to fix this in bug 351310.
Comment 7 Simon Bünzli 2006-10-20 05:09:58 PDT
*** Bug 357317 has been marked as a duplicate of this bug. ***
Comment 8 Simon Bünzli 2006-10-24 05:54:42 PDT
Created attachment 243344 [details]
work-around extension

Installing this extension should re-enable numeric accesskeys in most if not all relevant circumstances.
Comment 9 Jesse Ruderman 2006-10-25 10:10:27 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061019 Minefield/3.0a1

Alt+Shift+1 works for me on http://www.squarefree.com/start/.  What am I missing?
Comment 10 Simon Bünzli 2006-10-25 13:21:45 PDT
Created attachment 243506 [details]
work-around extension (version 2)

This version should re-enable most non-alphanumeric accesskeys as well - at least under Windows. Shifted characters still take priority though.

That's about the state of functionality I'd try to restore for Firefox 3.0 (with the main difference that unshifted characters should take priority and that it'd work as well on all platforms). Of course, that's not really up to me...

(In reply to comment #9)
> Alt+Shift+1 works for me on http://www.squarefree.com/start/.

You don't happen to be using either the numeric keyboard (which should still work) or a French or otherwise exotic keyboard layout?
Comment 11 Nigel Ramsay 2006-10-25 13:51:35 PDT
(In reply to comment #10)
> That's about the state of functionality I'd try to restore for Firefox 3.0
> (with the main difference that unshifted characters should take priority and
> that it'd work as well on all platforms). Of course, that's not really up to
> me...

I would suggest that the fix for this bug needs to be resolved sooner than Firefox 3.0. Although it may have a minor impact on "able bodied" users, the impact for disabled users is considerably higher. 
Comment 12 Lothar 2006-10-25 17:09:06 PDT
(In reply to comment #10)
> Created an attachment (id=243506) [edit]
> work-around extension (version 2)
> 
> This version should re-enable most non-alphanumeric accesskeys as well - at
> least under Windows. Shifted characters still take priority though.
I'd tested your fist work-around with success, I'll test the new one too.


> (In reply to comment #9)
> > Alt+Shift+1 works for me on http://www.squarefree.com/start/.
> 
> You don't happen to be using either the numeric keyboard (which should still
> work) or a French or otherwise exotic keyboard layout?

Maybe because he's using Minefield (FF3) not Bon Echo (FF2)!


(In reply to comment #11)
I'd like to see this for FF2 for the same reason.
Comment 13 Simon Bünzli 2006-10-27 16:51:55 PDT
(In reply to comment #12)
> Maybe because he's using Minefield (FF3) not Bon Echo (FF2)!

Indeed, it seems that bug 339723 has already taken care of the issue of numeric accesskeys not working under Windows.
Comment 14 Jesse Ruderman 2006-10-27 17:55:58 PDT
Ah, that explains why I haven't been experiencing this bug on trunk.  Is the patch from that bug appropriate for the Firefox 2 branch?
Comment 15 Simon Bünzli 2006-10-28 06:42:13 PDT
(In reply to comment #14)
> Is the patch from that bug appropriate for the Firefox 2 branch?
Best would be to ask Masayuki.

OTOH since that fix is Windows-only, we'd still have to care about the other two platforms. I'm currently waiting in bug 351310 for a design decision to that end by Mats and/or Neil.
Comment 16 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-10-28 22:44:12 PDT
(In reply to comment #15)
> (In reply to comment #14)
> > Is the patch from that bug appropriate for the Firefox 2 branch?
> Best would be to ask Masayuki.

"the patch" is for bug 339723? If so, the bug was fixed only on trunk, it's not landed on Fx2.
Comment 17 Jesse Ruderman 2006-10-28 22:56:17 PDT
Masayuki, would it be safe and correct to land that patch on the Firefox 2 branch, in order to fix this bug?  Or does Firefox 2 need a different fix?  (That's what I meant by asking whether it was "appropriate for the branch".)
Comment 18 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-10-28 23:17:26 PDT
(In reply to comment #17)
> Masayuki, would it be safe and correct to land that patch on the Firefox 2
> branch, in order to fix this bug?  Or does Firefox 2 need a different fix? 
> (That's what I meant by asking whether it was "appropriate for the branch".)

No. The bug is only on trunk in that time. The bug is not on Fx2. Because the bug is regression of bug 287179 that is fixed only on trunk. And the OS of this bug is set to "all". This bug is not relative to other key handling bugs of Windows.

I don't know where is handling the access keys on XP code...
We should find what bug is a cause of this regression.
Comment 19 Aaron Leventhal 2006-11-03 06:20:58 PST
*** Bug 359383 has been marked as a duplicate of this bug. ***
Comment 20 Aaron Leventhal 2006-11-03 13:35:09 PST
Please mark as blocking one of the 1.8.1.x branches. This is giving us grief in the accessibility community, because it messes up usability on sites designed for physically impaired users. A lot of those sites use numeric accesskeys to get around the conflict that accesskeys normally have.

For example see http://juicystudio.com/article/firefox2-accesskeys.php or discussions in mozilla.dev.accessibility.

Zeniko is asking that Mats help him decide what the correct safe is for the 1.8 branch, between several options.
Comment 21 Aaron Leventhal 2006-11-03 13:54:43 PST
The possible fix for this is in bug 351310.
Comment 22 Bob Easton 2006-11-03 19:14:01 PST
(In reply to comment #10)
> Created an attachment (id=243506) [edit]
> work-around extension (version 2)
> 
> This version should re-enable most non-alphanumeric accesskeys as well - at
> least under Windows. Shifted characters still take priority though.
> 
> ...

Doesn't work for my http://access-matters.com site, or for a large intranet site that serves 300,000 people which includes an unknown number of people who have been using those access keys for three years.

Bob Easton, IBM
Comment 23 Simon Bünzli 2006-11-03 23:51:06 PST
(In reply to comment #22)
> (In reply to comment #10)
> Doesn't work for my http://access-matters.com site

If it doesn't work, it won't for any website using numeric accesskeys. That means that you'd rather have to indicate your user agent, the specific OS you're using and the input locale used to test it.

Note that this hack has really only been tested under Windows. Under Linux this issue unfortunately doesn't seem to be as simple to fix (see bug 351310 comment #12).
Comment 24 Bob Easton 2006-11-04 10:43:47 PST
(In reply to comment #23)
> (In reply to comment #22)
> > (In reply to comment #10)
> > Doesn't work for my http://access-matters.com site
> 
> If it doesn't work, it won't for any website using numeric accesskeys. That
> means that you'd rather have to indicate your user agent, the specific OS
> you're using and the input locale used to test it.
> 

OS: WinXP Pro, SP2
UA: Gecko/20061010 Firefox/2.0
Locale: en-US
Comment 25 Simon Bünzli 2006-11-04 11:23:18 PST
(In reply to comment #24)
> OS: WinXP Pro, SP2
> UA: Gecko/20061010 Firefox/2.0
> Locale: en-US

Works for me. This rather looks like an extension incompatibility (or a mis-configuration of your Firefox installation).
Comment 26 Simon Bünzli 2006-11-08 11:35:01 PST
*** Bug 359976 has been marked as a duplicate of this bug. ***
Comment 27 Wayne McLean 2006-11-11 15:58:48 PST
alt+shift+number doesn't work for me on WinXP on any site including one of mine - http://www.mcleanhealthcare.com.au/node/327. Ctrl + number works fine on Mac version 2.0. Problem also occurs on 2.0 on Ubuntu Edgy Eft.

Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1) Gecko/20061010 Firefox/2.0

I work with many JAWS users at a blind/vi agency - generally sites should users numbers for access key or else they interfere with JAWS shortcuts.
Comment 28 Timwi 2006-11-12 03:18:04 PST
Apologies for Bugspam, but if you like the old behaviour (Alt+Key), here's an extension that works around this bug:

https://addons.mozilla.org/firefox/3812/
Comment 29 David J 2006-11-12 11:26:24 PST
Hi I've posted in a workaround in Bug 359383 (duplicate of this as I couldn't find it using the search) for all those who can't get/want to use the extension. It's fairly simple to do to get the old behaviour, but obviously it's not ideal for all of those people who will use accesskeys but will not look for/find these pages. Do we know if anyone's working on this? I know Bugzilla says no, but I was wondering if its being looked at?
Comment 30 Timwi 2006-11-12 16:50:38 PST
> It's fairly simple to do to get the old behaviour

No, it isn't. Your "workaround" (which is just a preference in Firefox) makes Alt+1 work, for example, but not Alt+! (which is Alt+Shift+1), etc. In the old behaviour, both worked. My extension fixes that.
Comment 31 David J 2006-11-13 09:50:05 PST
I'm sorry I didn't realise this was the place for one-up-manship, if my, by mine I mean read it elsewhere and posted it here since I though it was useful, workaround doesn't work then there is no issue using your extension or vice-versa. I saw people were having problems with your extension and thought it might be useful for people who didn't know (it's kind of academic whether its strictly a workaround or a preference) it. Anyhoo.
Comment 32 David J 2006-11-13 09:53:16 PST
Ps I'm not sure if anyone was actually having a problem with shifted characters since they are fairly rare, whereas accesskey + number are UK Government (and I'm sure other) standards.
Pps I'm sure youre extension/add-on is great
Comment 33 Daniel Veditz [:dveditz] 2006-11-20 11:25:59 PST
No owner for this one and we're running up against the 1.8.1.1 deadline. Minus for now, hope for a fix later.
Comment 34 Simon Bünzli 2006-11-21 12:59:40 PST
(In reply to comment #28)
> if you like the old behaviour (Alt+Key), here's an
> extension that works around this bug:

Do you happen to know any pages (or chrome bits for that matter) which actually use any of these accesskeys (namely !@#$%^&*()_+{}:"|? )?

(In reply to comment #33)
> No owner for this one and we're running up against the 1.8.1.1 deadline.

OTOH bug 351310 which intends to fix this issue has been set blocking1.8.1.1+ which might be enough for all practical purposes.
Comment 35 Timwi 2006-11-23 12:48:01 PST
> Do you happen to know any pages (or chrome bits for that matter) which actually
> use any of these accesskeys (namely !@#$%^&*()_+{}:"|? )?

Wikipedia uses both "-" (Preferences) and "+" (Add section). On US English keyboards, the former is a non-shift key, while the latter is a shift key. Whether you set ui.key.contentAccess to 4 or 5, either of the two is inaccessible.

Additionally, whether a website uses it or not is irrelevant.
Comment 36 Simon Bünzli 2006-11-29 08:06:37 PST
With the fixes to bug 351310, the "numeric accesskeys are broken" bits of this bug should be fixed for good. Please test the latest 2.0.0.1pre nightly builds (20061129) to ensure that this is indeed the case and that nothing else was broken in the process.

Should numeric accesskeys still not work under certain conditions (as I suspect is the case under Mac OS X with a French keyboard layout), please file new bugs and mark them as blocking this bug.

(In reply to comment #35)
Bug 303192 should take care of making all imaginable accesskeys accessible again. This shouldn't be a show-stopper for as good as all users though, since as you point out hardly any web pages use non-alphanumeric accesskeys in the first place (and IMHO rightly so).
Comment 37 Lothar 2006-11-29 15:52:46 PST
Verified for "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1pre) Gecko/20061129 BonEcho/2.0.0.1pre":
Works now for:
  - Dokuwiki ( http://wiki.splitbrain.org/playground:playground ) and tested keys at
  - Wikipedia ( http://de.wikipedia.org/wiki/Wikipedia:Spielwiese ): ".", "," and "+"
IMHO my two little tests are not sufficient for resolution fixed, more validation should be done, but thx so far!
Comment 38 Jay Patel [:jay] 2006-12-20 15:55:28 PST
Looks like the fix for bug 351310 fixed this bug. Marking FIXED.

Please reopen if anyone things this is still an issue on the branch.

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