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.
Cc'ing akkana because akkana was last seen diddling with Unix keyboard bindings.
this might be due to problems in bug 47426... dup?
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
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?
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 email@example.com (cc me and firstname.lastname@example.org 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 → ---
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...
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. ***
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.
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
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 ago → 18 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. :)
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!
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
You need to log in before you can comment on or make changes to this bug.