Is there any page online that you could link to which demonstrates this inconsistency?

In case there are conflicts with extensions, could you try the app in Firefox's Safe Mode? That's a standard diagnostic tool to bypass interference by extensions (and some custom settings). More info: Diagnose Firefox issues using Troubleshoot Mode.

You can restart Firefox in Safe Mode using

Help > Restart with Add-ons Disabled

In the dialog, click "Start in Safe Mode" (not Reset)

Any difference?

I'm having this problem on an internal web site, so I can't provide access to it.

The Safe mode had no impact.

It's interesting to me that the 3.6.28 version works perfectly. I'm not sure at what point this stopped working.

As far as I know, the way access keys work in Firefox hasn't changed since the 3.6 days.

You can configure Firefox to use Alt+key instead of Alt+Shift+key. Have you been doing that? Another user recently reported a problem with that; maybe this thread will help: ui.key.chromeAccess & Ui.key.contentAccess being ignored.

Yes, we configure Firefox to use just Alt+key, which works fine for us. Configuring it to use Alt+Shift+key does not change the behavior we're seeing.

At any point in time we might have several different data entry panels configured with the same set of Alt+keys, but only one is visible at a time. I'm wondering if the "hidden" panels are a problem now, but weren't in the older version?

Are you using the Alt+Shift key and the access key?

Does the access key show in the Inspector window and possibly the DOM Inspector if you inspect this element?

Maybe it is possible to post the code or setup page with the minimum code that shows this problem.

Did you check the Web Console or the Browser Console for error messages?

• https://developer.mozilla.org/Tools/Web_Console
• https://developer.mozilla.org/Tools/Browser_Console

It works the same using Alt+key and Alt+Shift+key (based on the configuration).

There are no entries made in either the web console or the browser console when the access key doesn't work.

The access key does show up as defined for the element (always a button in our case) when viewing it via the Inspector.

I can try and create a minimal page with the issue, but that will be tomorrow at the earliest.

Maybe it would be useful to have a little script to conduct a census of the accesskeys set in the page. You could open the web console (Ctrl+Shift+k), paste the following next to the caret (">") and press Enter. A new element is added at the end of the body with the results.

var aks=document.querySelectorAll("a[accesskey], button[accesskey], input[accesskey]"); var out=document.createElement("pre"); for(var i=0; i<aks.length; i++) out.appendChild(document.createTextNode("Tag:'"+aks[i].nodeName+"'; id:'"+aks[i].id+"'; name:'"+aks[i].name+"'; key:'"+aks[i].getAttribute("accesskey")+"'\n")); document.body.appendChild(out);

Note that this is no guarantee that an access key works. If an accesskey attribute is added via a script then the accesskey only works if it is done to a hidden element (display:none) (I add an accesskey 's' to the submit button of this forum via a bookmarklet).

I've removed the solved status of this thread for none to avoid confusion.
Feel free to re-add it when you solve this problem and possibly click Helpful to mark replies as such.

OK, that was very useful. The list shows me a few buttons that are not visible, and that use (some of) the same access keys. I'll try to figure out why they're showing up and post the results here tomorrow.

I've spent a lot of time with this now, and the problem is definitely caused by the "hidden" buttons that have overlap with the visible buttons, using the same access keys. As soon as I change (or remove) the access key definitions from the hidden buttons everything works as I expect.

So, I'm thinking that at some point after 3.6.28 the way the accesskey enabled elements are searched for must have changed. The DOM entries for the "hidden" buttons did not impact accesskey function in 3.6.28, but do now. I'll have to try and figure out a way around that.

Thank you for all the help - I now understand the behavior.

Hi jtinpc, thank you for the updated diagnosis. I'm not sure it's desirable to have hidden elements capture keystrokes, but in some old (Firefox 3 era) bugs I read, it was argued that users become accustomed to using keyboard shortcuts to activate commands on drop-down menus, and since those do not need to be opened (made visible) in order to work, for consistency, web pages should work the same way.