435326 - findbar keys highlight.accesskey conflicts with beginning of line mac os x keybinding

Status: RESOLVED FIXED

(Toolkit :: Find Toolbar, defect, P1)

Description

[Mike Polo]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

Mac OS X uses emacs keybindings for all dialog boxes.

some very common keybindings are 
control-p previous line
control-n next line
control-a beginning of line
control-e end of line

however when the findbar is open (command-F) the control-a key
is used to toggle "Highlight all" function on and off.

You should change the "highlight all" accesskey to a different key


Reproducible: Always

Steps to Reproduce:
1. browse to a web page
2. search for text within the page using command-f
3. use the ctrl-a key to go to the beginning of a line in any browser
   field (url bar, find area, etc)
Actual Results:  
the rather obscure function "highlight all" in the findbar will toggle on and off

Expected Results:  
cursor should move to beginning of line


I believe the basic text editing keystrokes should NOT be
repurposed to other functions

control-a should be beginning of line.

additionally, control-n and control-p move to previous and next matches.
This should be changed too.  I believe text boxes should take precedence.

If I happen to have the findbar open, and I type text into a text box,
hitting control-p and control-n instead of moving around in the text
box will start doing find features.

for instance, command-g correctly goes to the next match.  This is ok.
however control-n should not do this too.

the definition of control-a seems to be in:
/Applications/Firefox.app/Contents/MacOS/chrome/en-US.jar
in:
locale/en-US/global/findbar.dtd
as:
highlight.accesskey
next.accesskey
previous.accesskey

Comment 1

[Mike de Boer [:mikedeboer]]

Attachment: Bug 435326 - change accesskey for en_US 'Highlight All' from 'a' to 'l', to stop overriding Emacs-style input keybindings.

Review commit: https://reviewboard.mozilla.org/r/91412/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/91412/

Comment 2

[:Gijs (he/him)]

Comment on attachment 8808611 [details]
Bug 435326 - change accesskey for en_US 'Highlight All' from 'a' to 'l', to stop overriding Emacs-style input keybindings.

https://reviewboard.mozilla.org/r/91412/#review91246

ctrl-h seems to be emacs-style keybinding for backspace?

TBH, h and a are the most obvious here. Not sure what else to use or if we should just give up. Certainly don't think we should use "i" or whatever on Windows/Linux just because OS X and emacs are "special".

Comment 3

[Mike de Boer [:mikedeboer]]

How about 'l'?

Comment 4

[:Gijs (he/him)]

Comment on attachment 8808611 [details]
Bug 435326 - change accesskey for en_US 'Highlight All' from 'a' to 'l', to stop overriding Emacs-style input keybindings.

https://reviewboard.mozilla.org/r/91412/#review91252

r=me for using 'l', then, I guess.

Comment 5

[Mike de Boer [:mikedeboer]]

Comment on attachment 8808611 [details]
Bug 435326 - change accesskey for en_US 'Highlight All' from 'a' to 'l', to stop overriding Emacs-style input keybindings.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/91412/diff/1-2/

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9796c87f3a2d
change accesskey for en_US 'Highlight All' from 'a' to 'l', to stop overriding Emacs-style input keybindings. r=Gijs

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9796c87f3a2d

Comment 8

[WildcatRay]

Just a thought. Should this be for Mac OS builds only? Ctrl+a is a Windows function and will most likely be used instinctively by Windows users when attempting to "highlight all". With this change, you will be forcing Windows users to change what they would naturally do because of an issue that, AFAICT, is strictly on Mac OS.

Comment 9

[:Gijs (he/him)]

(In reply to WildcatRay from comment #8)
> Just a thought. Should this be for Mac OS builds only? Ctrl+a is a Windows
> function and will most likely be used instinctively by Windows users when
> attempting to "highlight all". With this change, you will be forcing Windows
> users to change what they would naturally do because of an issue that,
> AFAICT, is strictly on Mac OS.

No, this is an accesskey. On Windows you'd invoke it with alt-a. It's different from the "select all" windows function which has the shortcut (which isn't the same as an accesskey) ctrl-a. We're not changing the latter, only the former.

Comment 10

[protective1]

Windows user here.  Just updated to Firefox 52.0.  The key sequence "Ctrl-F, Alt-A" no longer invokes "Highlight All" like it used to.  Now the sequence is "Ctrl-F, Alt+L".  Maybe this was an intentional change, but not a good one.  It changed an easy one-handed sequence into a complicated two-handed sequence that forces me to take my hand off the mouse for a basic function that's used quite often.

Comment 11

[vs3]

Same here. This broke a very well working and convenient shortcut key, and replaced it with a cumbersome to use one. Please consider bringing ALT-A back for the "Select-All" function.
If you have to get voting on this one I'd guess the vast majority would prefer Alt-A than Alt-L as it's very easy to press with just one hand.
If this still requires further per-user customization I'd suggest making this a user-configurable option.

Comment 12

[malaquiasjp]

Linux user here and I also don’t understand how a MacOS-only issue could trigger a decision that harm the usability for users on all platforms. "Ctrl-F, Alt-A" was a convenient one-handed sequence that is not even close to the effort to do a "Ctrl-F, Alt-L", that requires to take the hand off the mouse and look to the keyboard, entirely breaking the work flow.
It makes me wonder with how many users in consideration this was decided. Please consider, if is not possible to bring it back as it efficiently was for years, at least give us the option to customize it.

Comment 13

[Doug®]

I won't go on endlessly about why I feel the change of "Alt-A" to "Alt-L", apart from the obvious inconvenience to Firefox users on every platform that is not Macintosh. (Do they still use their full name?)
Please do change this back for the benefit of the *majority* of Firefox users.  If you would like to do something special for a Mac version of Firefox, then please do so - just not at the inconvenience of the *majority* of Firefox users.
Thank you.

Comment 14

[Doug®]

I am surprised at the apparent lack of consideration given to the users concerned enough about this change to track down this "bug" and express how this change has negatively affected them.  I decided to put "bug" in quotes because this is not something that causes the browser to error/malfunction.

After further consideration of the purported bug, I feel confident that this is not only a single platform issue but that a rather small subset of Mac users would ever notice this.
I make this claim based on the reasonable assumption that the vast majority of MacOS Firefox users have never even heard of emacs, let alone become accustomed to using emacs key combinations instead of the arrow keys that are the intuitive way to move the cursor.

Even so, it is pointed out on this page that:

"the definition of control-a seems to be in:
/Applications/Firefox.app/Contents/MacOS/chrome/en-US.jar"

So this is obviously something that could, and I very much feel should, be changed only for MacOS Firefox versions.
In fact, I've read that this change was made only for en-US versions: https://support.mozilla.org/en-US/questions/1160688#answer-969668
It seems rather odd that, if this change is necessary, that MacOS users in London are left struggling without their emacs key bindings.

Why change a long familiar key binding for users of every other platform than MacOS?  (Again, I suspect a tiny subset thereof.)



Just to make an absurd assertion, what about the users who are much more comfortable with moving the cursor in a different editor, perhaps vi?  When I used Unix workstations I never bothered with emacs, I only used vi.

Comment 15

[ce]

I'm a macOS user and, although i appreciate the attempt, i have to agree that this fix is insufficient:

1. It seems to have upset a lot of non-Mac users.

2. The find bar still breaks Ctrl+W, which is the Emacs/readline sequence for deleting the previous word. Firefox supports this directly when using the 'Emacs' editor bindings[a], and it also supports it on the Mac if configured via Cocoa's native text bindings[b][c].

3. Probably most importantly, to the extent that the fix does help, it only affects en_US. As the previous commenter pointed out, nothing has changed for en_GB (what i use), en_ZA, and presumably several other locales. (I don't know what bindings these find-bar toggles are given for other languages, but i wouldn't be surprised at all if there were many that use Ctrl+A, Ctrl+E, Ctrl+W, &c. — Emacs bindings are not localised AFAIK.)

Is there no way to fix this more generally? Is it possible to detect when these toggle bindings would conflict with others? Could they be disabled/modified when 'Emacs' is selected in dev tools? At the very least, would having separate find-bar bindings for the Mac (where most non-power users hardly ever use the Ctrl key) allow for changing these to something less likely to conflict, like Ctrl+Shift+A / Ctrl+Shift+W?

Would it be appropriate to open a new bug requesting a more complete solution? I'm not sure about the etiquette.

PS: Bug # 577263 is a duplicate.

[a] https://github.com/mozilla/gecko-dev/blob/master/dom/xbl/builtin/emacs/platformHTMLBindings.xml

[b] https://bugzilla.mozilla.org/show_bug.cgi?id=282097

[c] https://www.google.com/search?&q=%22deleteWordBackward%22+defaultKeyBindings.dict

Comment 16

[:Gijs (he/him)]

(In reply to dana from comment #15)
> I'm a macOS user and, although i appreciate the attempt, i have to agree
> that this fix is insufficient:
> 
> 1. It seems to have upset a lot of non-Mac users.
> 
> 2. The find bar still breaks Ctrl+W, which is the Emacs/readline sequence
> for deleting the previous word. Firefox supports this directly when using
> the 'Emacs' editor bindings[a], and it also supports it on the Mac if
> configured via Cocoa's native text bindings[b][c].

Please file a separate bug for this with more details, if one is not already on file. One issue per bug.

> 3. Probably most importantly, to the extent that the fix does help, it only
> affects en_US. As the previous commenter pointed out, nothing has changed
> for en_GB (what i use), en_ZA, and presumably several other locales. (I
> don't know what bindings these find-bar toggles are given for other
> languages, but i wouldn't be surprised at all if there were many that use
> Ctrl+A, Ctrl+E, Ctrl+W, &c. — Emacs bindings are not localised AFAIK.)

Last I checked the en-GB localization was automatically generated from the en-US one with a bunch of automated replacements, so this is surprising to me. It's possible they don't re-run the script against strings that aren't new, or that we no longer create the en-GB localization that way. Either way, normally we'd fix different localizations by filing bugs against the respective localizations in e.g. https://bugzilla.mozilla.org/enter_bug.cgi?product=Mozilla%20Localizations&component=en-GB%20%2F%20English%20(United%20Kingdom)

> Is there no way to fix this more generally?

Not really.

> Is it possible to detect when
> these toggle bindings would conflict with others?

No. But also, even if we did, how would we come up with an alternative? Who would determine which binding is "more important"? And when do accesskeys really conflict? E.g. in https://hg.mozilla.org/mozilla-central/rev/1050ddd2bad8#l6.5 we have a whole bundle of duplicate access keys that are never both visible at the same time. You could only make the determination that there were duplicate keys at runtime, and only for declaratively specified keys (which in some way the emacs keybindings aren't, certainly not the builtin macOS ones that people have referenced here), and you'd have to make it continuously (ie what happens when UI elements are added "later", dynamically. And then once you determine which accesskey is more important, how do you pick a humanly-sensible alternative key?

That's all besides how you would even detect word boundaries in things like Japanese, or how you'd specify access keys for Arabic or Hebrew, or languages that use IME, and how you'd detect those situations.

> Could they be
> disabled/modified when 'Emacs' is selected in dev tools? At the very least,
> would having separate find-bar bindings for the Mac (where most non-power
> users hardly ever use the Ctrl key) allow for changing these to something
> less likely to conflict, like Ctrl+Shift+A / Ctrl+Shift+W?

No, the access key implementation is generic for the entire platform, and we can't really change it only for the find bar. If it bothers you, you could locally change ui.key.chromeAccess in about:config to the value 3 - see https://searchfox.org/mozilla-central/rev/403038737ba75af3842ba6b43b6e2fb47eb06609/modules/libpref/init/all.js#4146-4149 - which will change the access key modifiers to ctrl-shift everywhere in the browser chrome (but not in web content, for which see the contentAccess value).

> Would it be appropriate to open a new bug requesting a more complete
> solution? I'm not sure about the etiquette.

I don't think a more "complete"/holistic solution is feasible, per the above. This just isn't something we can automate. We can just tweak it as humans and cross our fingers that we didn't miss yet another edgecase.

Anyway, we could reconsider this bug, revert the change, and come up with a mac-specific access key... Mike, thoughts?

Comment 17

[ce]

Thanks for replying; i see your point(s).

> Please file a separate bug for this with more details, if one is not already on file.

Will do so.

> Either way, normally we'd fix different localizations by filing bugs against the respective localizations

I should probably do a comparison of the two with blank profiles to be completely sure, but if i'm not mistaken i'll do that; it seems undesirable in principle for them to differ.

> If it bothers you, you could locally change ui.key.chromeAccess in about:config to the value 3

I didn't know about this preference! I've only had a few minutes to play with it, but unless there's some horrible side-effect i'm not considering, this should be a perfectly acceptable solution for me personally. Thank you!

Comment 18

[Mike de Boer [:mikedeboer]]

I'd be happy to revert this patch for Windows and Linux, keeping it for Mac using #ifdef... sound feasible/ better than the status quo?

Comment 19

[vs3]

Hello Mike - I can say that from a PC prospective this would be a very welcome change. Let us know please of the release or version in which this is implemented so that we can test.

Comment 20

[:Gijs (he/him)]

(In reply to Mike de Boer [:mikedeboer] from comment #18)
> I'd be happy to revert this patch for Windows and Linux, keeping it for Mac
> using #ifdef... sound feasible/ better than the status quo?

Sounds OK to me. Can you file a separate dep bug so we can track release status etc.?