Closed Bug 319929 Opened 19 years ago Closed 9 years ago

accessibility.accesskeycausesactivation is broken

Categories

(Firefox :: Keyboard Navigation, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: Lupin.wp, Assigned: enndeakin)

References

()

Details

(Keywords: access, regression, Whiteboard: [bugday-2011-05-27])

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

I have set accessibility.accesskeycausesactivation=false in about:config. However, when I use an accesskey, the link is activated immediately. 

Reproducible: Always

Steps to Reproduce:
1. set accessibility.accesskeycausesactivation=false in about:config
2. go to http://en.wikipedia.org/
3. hit alt-x

Actual Results:  
The "Random article" link is focussed and activated.

Expected Results:  
The link should be focussed and not activated.

According to someone on IRC, this bug doesn't affect Firefox 1.5 on Windows. It also didn't affect Firefox 1.0.7 in Debian.
not reproducible in trunk
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
My instructions to reproduce this bug seem to have been faulty. Here's how I can do it:

1. set accessibility.accesskeycausesactivation=false in about:config
2. go to http://en.wikipedia.org/
3. hit alt-x. This works as expected: the link is focussed but not activated.
4. Restart firefox and repeat steps 2 and 3. The link is activated instantly.

Upon restart, accessibility.accesskeycausesactivation is still set to false in about:config, but it does not work until I manually toggle it to true and then false again.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Keywords: access
Component: Disability Access → Keyboard Navigation
QA Contact: disability.access → keyboard.navigation
I can confirm Lupin.wp@gmail.com's report.  If you set accessibility.accesskeycausesactivation to false, pressing a link's access key focuses the link without activating it.  However, once you quit FireFox and restart it, accessibility.accesskeycausesactivation still shows as false in about:config, but pressing a link's access key now activates the link instead of just focusing it.  Going to about:config and toggling the value of accessibility.accesskeycausesactivation makes things work again for the duration of the session, until Firefox is restarted again.
Assignee: nobody → mats.palmgren
In 2.0, accesskeys don't work under Windows XP.  The release notes indicate that Shift+Alt+Key will activate the link, but neither Alt+Key nor Shift+Alt+Key cause the link to be focussed nor activated.  I have tried this with accesskeys.accesskeycausesactivation true and with it false.

I'm using the main distribution under WinXP: (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0)
(In reply to comment #4)
Access keys work for me using FF2.0 and Windows XP, although I did change ui.key.generalAccessKey from -1 to 18 to make my access key just ALT by itself.

However, this bug is still a bug in FF2.0 -- if you change accessibility.accesskeycausesactivation to false and then close and restart FireFox, accessibility.accesskeycausesactivation still says that it is false in about:config, but access keys still cause activation unless you go back into about:config and toggle the setting of accessibility.accesskeycausesactivation back to true and then to false again.
I am afraid that in firefox-3.0-0.beta2.8.fc9.x86_64 we have just got the reverse -- even though this key with unwriteable name is set to true, shortcuts still don't activate.
This is still a bug in FF3.5 -- if you change
accessibility.accesskeycausesactivation to false and then close and restart
FireFox, accessibility.accesskeycausesactivation still says that it is false in
about:config, but access keys still cause activation unless you go back into
about:config and toggle the setting of accessibility.accesskeycausesactivation
back to true and then to false again.
Most likely a duplicate of bug 412787
sorry, other way around, this bug is older.
perhaps this feature was removed? 
It is indeed documented at http://www.mozilla.com/en-US/firefox/2.0/releasenotes/

regression range would help.
Keywords: regression
Version: unspecified → 3.0 Branch
WFM: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8a2) Gecko/20040617 Firefox/0.8.0+

Builds 2004062208, 2004062208, 2004062608, 2004070108, 2004070708, 2004070908, 2004070908 crash after profile manager.

Reproducible:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8a2) Gecko/20040713 Firefox/0.9.1+
20110318052756 Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0
Mozilla/5.0 (X11; Linux x86_64; rv:6.0a2) Gecko/20110527 Firefox/6.0a2
Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110527 Firefox/7.0a1
Whiteboard: [bugday-2011-05-27]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 3.0 Branch → Trunk
Possible suspects: bug 171366, bug 222297.
Less likely: bug 17602.
I confirmed that this bug still exists in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110526 Firefox/7.0a1. The value is saved, so when I restart Firefox after changing the pref from "true" (the default) to "false", it is not honoured, and the "random article" on en.wikipedia.org is activated where it wasn't right after toggling the pref and before restarting Firefox.

Looking at the code in nsEventStateManager.cpp, I didn't immediately see anything wrong. Also, although the above mentioned bugs were the only bugs in the range that actually touched this file, the patches themselves don't really seem to touch this behavior explicitly.
enn, any chance you might have an idea here?
Assignee: matspal → nobody
A proper regression range would be useful here. The one given above is too large.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #536885 - Flags: review?(Olli.Pettay)
Note that this is a check only done once at startup so it wouldn't be feasible to create a test.
Comment on attachment 536885 [details] [diff] [review]
Initialize the preference properly

So what caused this regression? Did the change break other pref handling?
Attachment #536885 - Flags: review?(Olli.Pettay) → review+
http://hg.mozilla.org/mozilla-central/rev/214ec6862ec5
Status: ASSIGNED → RESOLVED
Closed: 19 years ago13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110604 Firefox/7.0a1
Status: RESOLVED → VERIFIED
Target Milestone: --- → Firefox 7
Verified fixed in Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110605 Firefox/7.0a1
I am sorry, but with Mozilla/5.0 (X11; Linux x86_64; rv:9.0a2) Gecko/20111030 Firefox/9.0a2 (today's Aurora, binary from ftp.mozilla.org) I have the bad behavior again. This time just the opposite of what the original reporter observed. Even though I have accessibility.accesskeycausesactivation set to true, the link doesn't get activated.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Attached file about:support
Target Milestone: Firefox 7 → ---
I don't see this issue. If there is still a problem, please file a new bug with more details.
Status: REOPENED → RESOLVED
Closed: 13 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.