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
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.
I can confirm Lupin.firstname.lastname@example.org'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.
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.
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
Approximate pushlog (both builds have "08" as the hour): http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-06-17+06%3A00&maxdate=2004-07-13+08%3A00&cvsroot=%2Fcvsroot
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?
A proper regression range would be useful here. The one given above is too large.
Created attachment 536885 [details] [diff] [review] Initialize the preference properly
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?
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110604 Firefox/7.0a1
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.
I don't see this issue. If there is still a problem, please file a new bug with more details.