The default bug view has changed. See this FAQ.

accessibility.accesskeycausesactivation is broken

RESOLVED FIXED

Status

()

Firefox
Keyboard Navigation
RESOLVED FIXED
12 years ago
2 years ago

People

(Reporter: Lupin.wp, Assigned: Neil Deakin)

Tracking

({access, regression})

Trunk
x86
Linux
access, regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bugday-2011-05-27], URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
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
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 2

11 years ago
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 → ---

Updated

11 years ago
Keywords: access

Updated

11 years ago
Component: Disability Access → Keyboard Navigation

Updated

11 years ago
QA Contact: disability.access → keyboard.navigation

Comment 3

11 years ago
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.

Updated

11 years ago
Assignee: nobody → mats.palmgren

Comment 4

11 years ago
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

11 years ago
(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

9 years ago
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

8 years ago
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

8 years ago
Most likely a duplicate of bug 412787

Comment 9

8 years ago
sorry, other way around, this bug is older.
Duplicate of this bug: 412787
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
Keywords: regressionwindow-wanted

Comment 12

6 years ago
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]

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regressionwindow-wanted
Version: 3.0 Branch → Trunk

Comment 13

6 years ago
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
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?

Updated

6 years ago
Assignee: matspal → nobody
(Assignee)

Comment 17

6 years ago
A proper regression range would be useful here. The one given above is too large.
(Assignee)

Comment 18

6 years ago
Created attachment 536885 [details] [diff] [review]
Initialize the preference properly
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #536885 - Flags: review?(Olli.Pettay)
(Assignee)

Comment 19

6 years ago
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+
(Assignee)

Comment 21

6 years ago
http://hg.mozilla.org/mozilla-central/rev/214ec6862ec5
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago6 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

Comment 23

6 years ago
Verified fixed in Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110605 Firefox/7.0a1

Comment 24

6 years ago
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 → ---

Comment 25

6 years ago
Created attachment 570949 [details]
about:support
Target Milestone: Firefox 7 → ---
(Assignee)

Comment 26

2 years ago
I don't see this issue. If there is still a problem, please file a new bug with more details.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.