Last Comment Bug 319929 - accessibility.accesskeycausesactivation is broken
: accessibility.accesskeycausesactivation is broken
Status: RESOLVED FIXED
[bugday-2011-05-27]
: access, regression
Product: Firefox
Classification: Client Software
Component: Keyboard Navigation (show other bugs)
: Trunk
: x86 Linux
: -- normal with 6 votes (vote)
: ---
Assigned To: Neil Deakin
:
Mentors:
http://en.wikipedia.org/
: 412787 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-11 21:20 PST by Lupin.wp
Modified: 2015-10-05 10:43 PDT (History)
10 users (show)
enndeakin: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Initialize the preference properly (1.06 KB, patch)
2011-06-02 07:46 PDT, Neil Deakin
bugs: review+
Details | Diff | Splinter Review
about:support (32.32 KB, text/plain)
2011-11-01 02:12 PDT, Matěj Cepl
no flags Details

Description Lupin.wp 2005-12-11 21:20:23 PST
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.
Comment 1 Nian Liu(n/a in a long time) 2005-12-25 23:24:39 PST
not reproducible in trunk
Comment 2 Lupin.wp 2006-01-05 20:01:46 PST
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.
Comment 3 David Lauri 2006-02-02 08:41:13 PST
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.
Comment 4 Gus Michel 2006-11-10 06:01:06 PST
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)
Comment 5 David Lauri 2006-11-10 06:48:04 PST
(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.
Comment 6 Matěj Cepl 2008-01-17 05:42:46 PST
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.
Comment 7 David Lauri 2009-07-01 09:41:40 PDT
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.
Comment 8 Matěj Cepl 2009-07-03 14:05:49 PDT
Most likely a duplicate of bug 412787
Comment 9 Matěj Cepl 2009-07-03 14:06:10 PDT
sorry, other way around, this bug is older.
Comment 10 Wayne Mery (:wsmwk, NI for questions) 2010-02-28 12:07:19 PST
*** Bug 412787 has been marked as a duplicate of this bug. ***
Comment 11 Wayne Mery (:wsmwk, NI for questions) 2010-02-28 12:16:25 PST
perhaps this feature was removed? 
It is indeed documented at http://www.mozilla.com/en-US/firefox/2.0/releasenotes/

regression range would help.
Comment 12 [:Aleksej] 2011-05-27 08:06:17 PDT
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
Comment 14 Marco Zehe (:MarcoZ) 2011-05-27 09:44:45 PDT
Possible suspects: bug 171366, bug 222297.
Less likely: bug 17602.
Comment 15 Marco Zehe (:MarcoZ) 2011-05-27 09:59:04 PDT
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.
Comment 16 Marco Zehe (:MarcoZ) 2011-05-27 10:01:56 PDT
enn, any chance you might have an idea here?
Comment 17 Neil Deakin 2011-05-30 03:24:10 PDT
A proper regression range would be useful here. The one given above is too large.
Comment 18 Neil Deakin 2011-06-02 07:46:03 PDT
Created attachment 536885 [details] [diff] [review]
Initialize the preference properly
Comment 19 Neil Deakin 2011-06-02 07:46:55 PDT
Note that this is a check only done once at startup so it wouldn't be feasible to create a test.
Comment 20 Olli Pettay [:smaug] (vacation Aug 25-28) 2011-06-03 02:56:55 PDT
Comment on attachment 536885 [details] [diff] [review]
Initialize the preference properly

So what caused this regression? Did the change break other pref handling?
Comment 22 Marco Zehe (:MarcoZ) 2011-06-06 05:08:02 PDT
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110604 Firefox/7.0a1
Comment 23 [:Aleksej] 2011-06-06 06:42:37 PDT
Verified fixed in Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110605 Firefox/7.0a1
Comment 24 Matěj Cepl 2011-11-01 02:11:00 PDT
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.
Comment 25 Matěj Cepl 2011-11-01 02:12:20 PDT
Created attachment 570949 [details]
about:support
Comment 26 Neil Deakin 2015-10-05 10:43:54 PDT
I don't see this issue. If there is still a problem, please file a new bug with more details.

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