161009 - Please change Forward and back menu commands back to arrow keys

Status: VERIFIED DUPLICATE of bug 160556

(Camino Graveyard :: Toolbars & Menus, defect)

Description

[Will Cosgrove]

In the newest nightly builds (8/4/02) the forward and back menu commands are
command ] or command [.  Please put them back to arrows, there are several
reasons for doing this.  First, all other browsers are set up like that, second
Microsoft mice are set up to use those keys for forward and back (and can't be
changed).  Third, it's easier to use arrow keys then it is to use the bracket
keys.  Forth, Chimera started with arrows keys, then moved to bracket keys,
people hated it, so they moved it back to arrows.  But now, for some reason they
are back as brackets...sigh.

Comment 1

[Lauri Kieksi]

I agree, the arrow keys are much more accessible, especially on International
layouts where the brackets are buried under multiple modifier keys. Why not just
have Command-Arrowkeys mirror the functionality of Command-Brackets? Best of
both worlds.

Comment 2

[Greg K.]

Will, the command+arrows combinations are reserved by Apple for text field
navigation.

Recommend WONTFIX.

Comment 3

[Will Cosgrove]

Greg, I'm all for following HIG as much as the next guy, but you rarely need to
use editfields in a browser while you're always using the forward-back command.
 Thus, it should be mapped to the simpliest/most obvious key combo possible.

Comment 4

[john]

I agree with Greg. Users of web-based email services and similar web apps use 
textfields *quite* often, and the behaviour of those fields should follow the 
expected navigation shortcuts. In addition, Cmd-[] have been standard back/
forward shortcuts in Mac browsers for a looong time. Recommend WONTFIX

Comment 5

[Lauri Kieksi]

Until Chimera is localizable (bug 150081), shortcuts that are impossible or very
hard to type on International layouts should be avoided if at all possible. It's
an accessibility and usability issue for most non-Americans.

Just implement some checking routines: Command-arrow trapped. Is the user in an
editfield? If not, go back. If yes, pass it onto the editfield. This is related
to bug 152659 in that it's be easier for the user to tell if an editfield has
focus or not if proper Aqua focus rings are used.

As a side note, it's not like the current text widgets follow Apple's specs
anyway, since they're Gecko stuff.

Comment 6

[Simon Fraser [no longer active]]

> As a side note, it's not like the current text widgets follow Apple's specs
> anyway, since they're Gecko stuff.

They follow most of the key shortcuts for text navigation and selection already.

It's difficult for us to allow Command-arrow key combos only when you're not in
a text field, because Cocoa gets the key shortcut first, and matches it to the
menu items (so it never gets to gecko).

Comment 7

[S Woodside]

> Will, the command+arrows combinations are reserved by Apple for text field
> navigation.

It's nice to follow HIG guidelines, and I agree that in this case there is an
ambiguity. Since textfields are sometimes present on web pages it is "elegant"
to simply remap "Back" to cmd-[. However this problem is easily solved from a UI
design standpoint by specifying that Cmd-arrow only goes back if you are not
editing a text field. This is OK since the only time a user will hit
command-arrow and expect to move their cursor is when they are editing a
text-field, and they usually know when they are doing that.

There is the occasional case where a javascript sticks you in a text field
without your knowledge, that's obviously going to result in a user going
cmd-arrow and getting confused. However it is important to weigh that situation
against the situation of people expecting cmd-arrows to go back and forward.
Also there is the HI issue in terms of ergonomics to think about with the way
keyboards are arranged, since back/forward are the most common keyboard actions
AFAIK.

Also there are other ways to mitigate the situation I described with being in a
textfield without your knowledge. One is to draw their attention to the
textfield, by flashing the focus border, system beep, or whatnot. 

> It's difficult for us to allow Command-arrow key combos 
> only when you're not in a text field, because Cocoa gets 
> the key shortcut first, and matches it to the
> menu items (so it never gets to gecko).

In that case unhook the cmd-arrows from the cocoa menus and handle it some other
way. This is important.

Comment 8

[Simon Fraser [no longer active]]

What about when focus is in the URL bar? Command-arrow keys should do text
navigation there too.

Comment 9

[S Woodside]

This bug is really making it hard for me to stay on the nightlies as opposed to
0.4.0. Maybe I'm an old fuddy-duddy but my hands are hardwired to use cmd-arrows
for forward and back. I have the feeling that this will be true of the general
public.

As far as mapping the keys go, you are already handling PageUp and PageDown in
some way since they don't function while I'm typing inside a textfield. Since
obviously a decision has been made to have that functionality work that way, it
can easily be applied to cmd-arrows as well.

Also I checked Mozilla 1.1 on mac os x 10.1.5, and they handle textfields (and
the uRL bar too, good catch) the way that has been proposed in the comments above.

Recommend bumping this bug up to Critical. I forsee a lot of people are going to
be irritated if they find that their favorite key combination has been remapped.

Comment 10

[Wincent Colaiuta]

I also recommend WONTFIX for the same reasons others have stated in comment 2,
comment 4 and comment 8 of this bug.

Comment 11

[Simon Fraser [no longer active]]

Dup.

*** This bug has been marked as a duplicate of 160556 ***

Comment 12

[sairuh (rarely reading bugmail)]

v