49407 - Accelerators for back and forward not hooked up

Status: VERIFIED FIXED

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

Description

[Jeffrey Baker]

On Linux build 2000-08-17-13, the keyboard accelerators (shortcuts) no longer
work.  The prevous accelerator was alt+right arrow for forward, and alt+left
arrow for back.  These keys no longer work.  In the "Go" menu, the accelerators
are listed as "Ctrl+" and "Ctrl+", which I suppose must be a mistake.  This is a
regression.

Comment 1

[Jeffrey Baker]

Cc'ing akkana because akkana was last seen diddling with Unix keyboard bindings.

Comment 2

[sairuh (rarely reading bugmail)]

this might be due to problems in bug 47426... dup?

Comment 3

[Akkana Peck]

The modifier key for Unix switched last week to control- rather than alt-. 
If you want the old alt bindings back, do this in user.js or prefs.js:
user_pref("ui.key.acceleratorKey", 18);
user_pref("ui.key.menuAccessKey", 0);
Control-leftarrow and control-rightarrow are working fine for me on today's
build.

Comment 4

[Jeffrey Baker]

ctrl-right and ctrl-left are the default bindings for next workspace and
previous workspace on GNOME installations.  Thus the accels for forward and back
won't work out of the box on Slackware 7.1, Red Hat 7, and anything else that is
shipping GNOME as the desktop.

What ever happened to ctrl-[ and ctrl-] for back and forward?

Comment 5

[Akkana Peck]

Please see all the comments in bug 22515, bug 27614 and various other bugs duped
to those two.  There were a lot of people asking for us to switch from control
to alt and use the same bindings as on Windows.  I've given up trying to express
any opinion on these bindings beyond "they should be configurable instead of
compiled in"; please file a bug to [e-mail] (cc me and
[e-mail] and add a note to this bug in case anyone else wants to join
in the fun) if you think the defaults should be different from what they are.  I
don't make those decisions.

Comment 6

[sairuh (rarely reading bugmail)]

jwb, which window manager are you using? that's what's catching and misreading
the event. i have afterstep and see the same thing as you. (another example:
when Alt was the accelerator key, alt+q would return to window, ie, "warp back"
instead of quitting mozilla.)

spoke recently w/akkana, and i'm gonna reopen this for the nonce.

we have a couple choices here:

1. the user will have to reset the keybinds (for their wm) such that it doesn't
conflict with mozilla's. would need to document this, o'course. if we went this
route, then this bug would be marked invalid, i guess.

2. reinstate the former accelerators of ctrl+[ for back and ctrl+] for fwd, for
only unix builds. while this would satisfy some folx, i have this strong feeling
that we'll be annoying other unix users with such a change... unless there'll
still be some other way a user could change this on her/his own.

am cc'ing other folx to see if there are other alternatives here. thx!

Comment 7

[timeless]

I think i rambled on a solaris bug about the need for very flexible 
keybindings.

Please read bug 13168.

As for simpler approaches also known as chaotic surpise the user:
a) determine the window manager, ask it if keybindings are available
- when they aren't pick the next choice
why this works: users will read the menus and learn the key combos
? you've got to be kidding, users don't read.
b) On first launch (of profile) give the user a guided tour of the 
keybindings, with simple toggles
c) Force them to change window managers
? but that's the prefered: oh great...

Comment 8

[Peter "jag" Annema]

One thing I haven't seen here (might be in one of the comments on the other bugs though) is that NS 4.7x on Windows uses alt-left and alt-right to navigate back and forward. Mozilla should do this too, on Windows, and because of all those cries for Unix keybindings matching the Windows ones, on Unix too. Btw, IE5 uses alt-left and alt-right for back/forward navigation too.

Comment 9

[sairuh (rarely reading bugmail)]

*** Bug 47806 has been marked as a duplicate of this bug. ***

Comment 10

[Peter "jag" Annema]

Well, it seems that the per platform "platformNavigationBindings.xul" files 
allow us to make this alt+left and alt+right again.

In xpfe/browser/resources/content/unix/platformNavigationBindings.xul:
12     <!-- proper arrow key navigation, 4.xP -->
 13     <key id="goBackKb" xulkey="true" keycode="VK_LEFT" 
observes="Browser:Back"/>
 14     <key id="goForwardKb" xulkey="true" keycode="VK_RIGHT" 
observes="Browser:Forward"/>

Remove the xulkey attribute and add ``alt="true"''. This is already the case for 
the windows platformNavigationBindings.xul.

However, it won't show these keys in the go menu.

Attaching patch.

Comment 11

[Peter "jag" Annema]

Attachment: [patch] Make alt-left/right be navigate back/forward again after global switch from alt -> ctrl

Comment 12

[sairuh (rarely reading bugmail)]

thx, jag! i've added patch and review kw's so that this can be reviewed in
checked in asap.

Comment 13

[Peter "jag" Annema]

My apologies, sairuh. I completely forgot to mention here I had already checked
that patch in. r=ben.

I'm marking this bug fixed and will see if there's a bug on showing alt+<key> in
menus.

Comment 14

[sairuh (rarely reading bugmail)]

np, jag. btw, when was the patch checked in? i'm looking at an optimized [albeit
commercial] build from 2000.09.11.08, and don't see the shortcuts displayed in
the Go menu. (then again, if that build was spun before your checkin, that'd
explain why. :)

Comment 15

[Peter "jag" Annema]

Ah, I see I removed a bit too much from my previous comment. I checked this in
09/08/2000 21:07.

The menu code currently won't display accelerators unless they're using the
default xulkey and I don't think it knows how to display <- and ->.

That should explain why you're not seeing them :-)

Since the accelerators themselves are hooked up, I marked this bug fixed.

Comment 16

[sairuh (rarely reading bugmail)]

my brain is leaking --i confused this for bug 47426 (where menus cannot display
special chars like -> and so forth). sorry bout that.

anyhow, i need to adjust my ever lovin' wm (afterstep) so that it stops using
either the alt+arrow or ctrl+arrow accelerators (ie, before mozilla has a
chance). so, am gonna add 'verifyme' for anyone to feel free to verify this (ie,
if they get to it before i do). thx!

Comment 17

[sairuh (rarely reading bugmail)]

if someone else could verify this, that'd be great. i haven't had time to clear
up my window manager issues (if it is indeed causing blockage here for me).

Comment 18

[sairuh (rarely reading bugmail)]

vrfy fixed...some time ago. :)