736837 - HTML accesskeys in web pages don't work anymore on Mac OS X (CTRL+key)

Status: RESOLVED WONTFIX

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Francesco Lodolo [:flod]]

Current build: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120317 Firefox/14.0a1

I've just realized that accesskeys don't work anymore inside webpages (CTRL+key). Not tested yet on other platforms, issue should be recent.

Comment 1

[Francesco Lodolo [:flod]]

Builds taken from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

2012-03-16-03-11-51-mozilla-central -> ok
2012-03-17-03-11-50-mozilla-central -> accesskeys don't work

Comment 2

[Francesco Lodolo [:flod]]

Accesskeys work fine on Linux
Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120318 Firefox/14.0a1

I'm not really good at browsing code on central+hg, but could it be bug 726072?

Comment 3

[Marcia Knous [:marcia]]

Moving to core accessibility component.

Comment 4

[Marcia Knous [:marcia]]

Francesco: Can you provide an example page where you are seeing this for testing purposes? Grazie.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to Francesco Lodolo [:flod] from comment #2)

> I'm not really good at browsing code on central+hg, but could it be bug
> 726072?

no

Comment 6

[Francesco Lodolo [:flod]]

Even this page is ok as a test (CTRL+L is supposed to take you to the last comment). 

I was trying with Chrome and now I realized that we have the same shortcut: CTRL+ALT+accesskey (instead of CTRL+accesskey).

When did this change??

Comment 7

[Francesco Lodolo [:flod]]

Not sure why I wasn't able to find this the first time.

Firefox 14
ui.key.contentAccess = 2

Firefox 16.0a1
ui.key.contentAccess = 6

Changeset (Bug 728103)
http://hg.mozilla.org/mozilla-central/rev/69a0d319fa74

Doc
https://developer.mozilla.org/en/HTML/Global_attributes#attr-accesskey

I suppose this bug should be closed, not sure how (invalid?)

Comment 8

[Marcia Knous [:marcia]]

Resolving as WFM.

Comment 9

[Francesco Lodolo [:flod]]

Thanks Marcia. BTW I realized why I didn't found the new combination before, filed bug 763211 for that.

Comment 10

[jjrdev]

i see the docs saying its now cntl alt + accesskey on firefox osx  but today after updating to firefox 14 this seems buggy

if i load a page in an iframe and that iframe contains an accesskey shortcut it doesnt work

Comment 11

[Tantek Çelik]

I think this bug should be re-opened and ctrl-key restored as the way accesskey works (that is bug 728103 should be reverted). This is a case where blindly copying Safari/Chrome makes (made) our UX worse.

Comment 12

[Tantek Çelik]

(and I'm speaking as someone who actually daily uses webapps with accesskeys for speed/efficiency - adding another key to hold down hurts that dramatically - I'm curious if any of the folks advocating ctrl-opt-key actually use accesskeys at all in webapps, if not, please do a study with people who actually *use* accesskeys before making such regressive changes).

Comment 13

[:Gavin Sharp [email: [e-mail]]]

The rationale in bug 728103 comment 0 seems sound, and isn't just "let's copy Safari". Even despite that, consistency with other browsers has some value too, and shouldn't be dismissed entirely. As Masayuki explained in bug 728103 comment 13, you can change a pref locally if this is seriously harming your productivity, but I don't see any reason to believe that your particular preference is dominant - we can re-evaluate if we get additional feedback.

Comment 14

[jjrdev]

maybe there should be a feature in firefox preferences so the end user can easily decide on what accesskey combination works best for them. After all, this feature is meant to be for accessibility and not all users will understand how to "change ui.key.contentAccess from 6 to 2"

Comment 15

[Tantek Çelik]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #13)
> The rationale in bug 728103 comment 0 seems sound

It is not. The rationale appears nothing more than capricious:

1. What is the specific user-scenario where a conflict results? Running emacs in a browser? URL? Steps to reproduce?
2. Who here (anyone?) is using that user-scenario, and if no one here, show me a study demonstrating real users encountering real problems or else I call hypothetical problem.

>, and isn't just "let's
> copy Safari".

The UI-review+ comment was *just* that: https://bugzilla.mozilla.org/show_bug.cgi?id=728103#c4

> Even despite that, consistency with other browsers has some
> value too,
> and shouldn't be dismissed entirely. 

If the consistent behavior is functionally equivalent/similar, then yes.

However, not in a case like this, where the inconsistent behavior is actually an *advantage* for Firefox, for the users of said feature.

And for the users who don't use the feature, the consistency doesn't matter.

> As Masayuki explained in bug
> 728103 comment 13, you can change a pref locally if this is seriously
> harming your productivity,

How about this, we have:
* theoretical problem: Control+Something is used by emacs like keyboard shortcuts on Mac
* actual problem: Control+something is much more efficient/usable for accesskey users than ctrl+opt+something

The bias for default behavior should be toward those that have the actual problem.

Those that have the theoretical problem (bug 728103) should be advised to change a pref locally, not those who have the actual problem.


> but I don't see any reason to believe that your
> particular preference is dominant

The control+something preference is dominant because it's the only actual data point you have from daily users of accesskey shortcuts on Mac.

So far, all the folks who say they use accesskey daily have this preference.

Only those folks who don't use accesskey daily are expressing a desire to change this functionality which doesn't affect them.

> - we can re-evaluate if we get additional
> feedback.

Please re-evaluate based on the fact that 728103 as a theoretical problem should have never resulted in a code change in the first place.

Comment 16

[:Gavin Sharp [email: [e-mail]]]

(In reply to Tantek Çelik from comment #15)
> 1. What is the specific user-scenario where a conflict results? Running
> emacs in a browser? URL? Steps to reproduce?

1) Load data:text/html,<input accesskey="k">
2) Enter something in the search bar
3) Press Ctrl+A, Ctrl+K

Expected: Ctrl+A goes to beginning of line, Ctrl+K deletes the line
Actual: Ctrl+A goes to the beginning of the line, Ctrl+K focuses the input on the page

> The UI-review+ comment was *just* that:
> https://bugzilla.mozilla.org/show_bug.cgi?id=728103#c4

It was one of the reasons, and perhaps the only one limi cared about. That doesn't mean it was the only reason.

> * theoretical problem: Control+Something is used by emacs like keyboard
> shortcuts on Mac

There's nothing "theoretical" about this problem, it just doesn't affect you personally.

> The control+something preference is dominant because it's the only actual
> data point you have from daily users of accesskey shortcuts on Mac.
> 
> So far, all the folks who say they use accesskey daily have this preference.

The reporter of bug 444960 has the opposite preference. Given the lack of a clear consensus about the most preferred behavior, defaulting to matching the behavior of both the system and other browsers seems sound.