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.

(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?

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

(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.

(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.

Regression from bug 340902. One suggestion for how to fix this in bug 351310.

*** Bug 357317 has been marked as a duplicate of this bug. ***

Installing this extension should re-enable numeric accesskeys in most if not all relevant circumstances.

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?

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?

(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.

(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.

(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.

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?

(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.

(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.

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".)

(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.

*** Bug 359383 has been marked as a duplicate of this bug. ***

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.

The possible fix for this is in bug 351310.

(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

(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).

(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

(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).

*** Bug 359976 has been marked as a duplicate of this bug. ***

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.

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/

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?

> 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.

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.

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

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.

(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.

> 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.

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).

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!

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.