The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in Firefox 52

Status

()

Toolkit
Find Toolbar
P1
normal
RESOLVED FIXED
9 years ago
13 hours ago

People

(Reporter: Mike Polo, Assigned: mikedeboer)

Tracking

(Blocks: 1 bug)

unspecified
mozilla52
PowerPC
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
str
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
Product: Firefox → Toolkit
(Assignee)

Updated

a year ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

a year ago
Priority: -- → P1

Updated

11 months ago
Blocks: 1271782
Comment hidden (mozreview-request)
(Assignee)

Updated

5 months ago
Assignee: nobody → mdeboer
Status: NEW → ASSIGNED

Comment 2

5 months ago
mozreview-review
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".
Attachment #8808611 - Flags: review?(gijskruitbosch+bugs)
(Assignee)

Comment 3

5 months ago
How about 'l'?

Comment 4

5 months ago
mozreview-review
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.
Attachment #8808611 - Flags: review+
Comment hidden (mozreview-request)

Comment 6

5 months ago
Pushed by mdeboer@mozilla.com:
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

5 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/9796c87f3a2d
Status: ASSIGNED → RESOLVED
Last Resolved: 5 months ago
status-firefox52: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52

Comment 8

5 months ago
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

5 months ago
(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.
Depends on: 1335218
QA Whiteboard: [good first verify]

Comment 10

15 days ago
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.

Updated

13 hours ago
Depends on: 1351534
You need to log in before you can comment on or make changes to this bug.