Accelerators for back and forward not hooked up

VERIFIED FIXED

Status

()

P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: jwbaker, Assigned: don)

Tracking

({platform-parity, regression})

Trunk
x86
Linux
platform-parity, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Cc'ing akkana because akkana was last seen diddling with Unix keyboard bindings.
this might be due to problems in bug 47426... dup?

Comment 3

18 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

18 years ago
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

18 years ago
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 don@netscape.com (cc me and
german@netscape.com 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.
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!
Status: RESOLVED → REOPENED
Keywords: pp, regression
Resolution: WORKSFORME → ---

Comment 7

18 years ago
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

18 years ago
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.
*** Bug 47806 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
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

18 years ago
Created attachment 14306 [details] [diff] [review]
[patch] Make alt-left/right be navigate back/forward again after global switch from alt -> ctrl
thx, jag! i've added patch and review kw's so that this can be reviewed in
checked in asap.
Keywords: nsbeta3, patch, review

Comment 13

18 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
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

18 years ago
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.
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!
Keywords: verifyme
Keywords: qawanted
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).
vrfy fixed...some time ago. :)
Status: RESOLVED → VERIFIED
Keywords: verifyme

Updated

18 years ago
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.