Reproduce: 1. On Mozilla Linux, try to go back (history.go(-1)) by keyboard only. Actual result: Neither any Ctrl + right arrow, nor the right Alt key (AltGr) work. Only Left Alt + Right Arrow works. These two keys cannot be pressed at the same time with one hand. Expected result: Shortcuts for forward/backward are, given that they are frequently used and non-destructive, easy to trigger with one hand. In particular, Ctrl + Arrows and possibly Ctrl + <some keys on the left side of the keyboard>. Additional Comments: A "shortcut" is supposed to be either - faster than other methods - more accessible In both cases, this fails. - If my hand is on the mouse and I want to use the keyboard shortcut in order to be faster, I can't. - If my right hand is busy (e.g. with holding a phone), and I want to use the keyboard shortcut with the left hand, I can't. On Unix, we moved *all* shortcuts from Alt to "Command Key" (dunno the name, by default mapped to Ctrl) on Unix, and completely broke 4.x compatibility for functions like Close Window and Cut/Paste/Copy. Why is exactly *this* shortcut hardcoded to Alt? Don't tell me "Because this is how 4.x Windows does it", or I'll kill you. This was IMO (and I read a similar opinion on a webpage, don't remember URL) one of the most dumb shortcuts in 4.x. No need to copy the bad parts.

I'm sure you meant "go forward (history.go(1))"... Do accel (ctrl by default, alt if you specified so) [ and ] work for you? On my keyboard (the one that comes with a lot of Toshiba laptops), I only have one ctrl, which is all the way to the left, so making ctrl left/right navigate back/forward would make your life easier and mine less easy, not to mention that in my window manager ctrl left/right are used to flip through virtual desktops. I guess the best fix would be to make altgr left/right work, except you mentioned having that hotkeyed for scrolling? See also bug 55438

> Do accel (ctrl by default, alt if you specified so) [ and ] work for you? It works, but is also extremely difficult to reach, because "[" is AltGr + 8 on German keyboards. > I guess the best fix would be to make altgr left/right work Why should you hardcode to Alt, if all other shortcuts are on Accel? > On my keyboard (the one that comes with a lot of Toshiba laptops) Laptop keyboards are not supposed to be comfortable. Backspace and shift+backspace are also good idea IMO.

> > Do accel (ctrl by default, alt if you specified so) [ and ] work for you? > It works, but is also extremely difficult to reach, because "[" is > AltGr + 8 on German keyboards. Urgh, okay, so those are out... > Backspace and shift+backspace are also good idea IMO. Backspace is page up on unix (space is page down). > > On my keyboard (the one that comes with a lot of Toshiba laptops) > Laptop keyboards are not supposed to be comfortable. Yeah, right :-) Even if that is true, why should _we_ add discomfort? Btw, the solution doesn't have to be exclusive, it can be added onto the current accelerator keys. If we can find a way which works for you and doesn't clash with any existing accelerators, it's easy enough to add that. > > I guess the best fix would be to make altgr left/right work > Why should you hardcode to Alt, if all other shortcuts are on Accel? See below... ------- Additional Comments From Matthew Thomas (mpt) 2000-10-06 22:25 ------- jag: making Ctrl+Left/+Right modal in that way would be exceptionally bad UI -- for example, you might be trying to use the shortcuts to flip through several pages one of which uses a script to put focus in a text field. Ctrl+Left/+Right should always just do word navigation, and Alt+Left/+Right should always just do document navigation.

Oh, I'm getting a headache with all these shortcuts ... What is the standard keyboard combination (if any) for going to the previous/next word in GNOME/KDE apps? Following the principle of consistency of the closest aspects, I would suggest that consistency with whatever that is (i.e. don't use the same shortcut for Back/Forward), is more important than consistency with 4.x. [ and ] are not i18n-friendly (obviously), and the idea of using Backspace for anything other than deleting objects seems like asking for trouble.

> What is the standard keyboard combination (if any) for going to the > previous/next word in GNOME/KDE apps? ctrl+left/right arrows I don't see the collision as a problem. We are highly modal between "in textfield" and "not in a widget" anyway (e.g. arrow up/down, mousewheel). Extending this modality (especially in navigation) sounds more like consistency than a problem to me.

If you are using Up and Down to scroll through a page, by definition you are spending some time on that page. So modality is much less of a problem than if you press Ctrl+Left repeatedly to flip back to the page you were on ten pages ago and you (seemingly inexplicably) get stuck halfway because one of those pages happens to be <http://www.google.com/> where a script gives focus to a text field. On Windows, Alt+Left/Right have been used to go Back/Forward ever since version 1.x, on both Mozilla and IE. This is for the very good reason that Ctrl+Left/Right has a well-defined existing meaning (previous/next word). The obvious fix for this bug would be to make the left and right Alt keys behave identically (as far as *any* Mozilla keyboard combo is concerned) on Unix.

Could be a dupe of bug 47079.

> The obvious fix for this bug would be to make the left and right Alt keys > behave identically (as far as *any* Mozilla keyboard combo is concerned) on > Unix. Alt (LeftAlt) != AltGr (RightAlt) AltGr + Left/Right Arrow is the shortcut for the horizontal scrollbar on (Mozilla and 4.x) Linux.

hokay, i've checked in jglick's latest version of the accelerator ui spec at: http://mozilla.org/projects/ui/netscape/accel_keys/index.html might take a while for the latest version to actually appear on the website. nevertheless, it looks like (if you read the "Other Accelerators" section) Alt is the accel key used with the left and right arrows for back and forward, respectively. is this really what we want for the back/fwd shortcuts? (according to this spec, i presume Option will be what's used on the Mac, and Alt for win32 and linux.)

> AltGr + Left/Right Arrow is the shortcut for the horizontal scrollbar on > (Mozilla and 4.x) Linux. Why does scrolling left and right need a modifier at all???

Em, you're right :). You don't need AltGr for that.

rtm-, this is for the trunk, not the RTM.

If I understand this correctly, the current best solution is to make AltGr be "just another alt (or is that meta?)", or make it so we can refer to it in the modifiers attribute of a <key/>? Sounds like a new bug should be filed for that (if there isn't one already), in which case this either automatically gets fixed, or I'll need to add <key/>s for AltGr + left/right.

> The obvious fix for this bug would be to make the left and right Alt keys behave > identically (as far as *any* Mozilla keyboard combo is concerned) on Unix. No, as I said: Alt != AltGr, just like 1 on main key block != 1 on number block. E.g. you can enter chars (e.g. for the case that your keyboard doesn't offer that char) using their char code with AltGr + CharCode on number block. This doesn't work, if you use Alt or the number key on the main key block. We *could* add AltGr+Left-/RightArrow as key combo, but I still like Access + Left-/RightArrow better. > get stuck halfway because one of those pages happens to be > <http://www.google.com/> where a script gives focus to a text field. You can disable that. IIRC, it's even off by default. I don't know other pages which do that. If there are, then either disable JS or don't visit that pages. Chances are that they are bad anyway. > On Windows, Alt+Left/Right have been used to go Back/Forward ever since > version 1.x, on both Mozilla and IE. I don't care. *All* key shortcuts on Unix changed. Do you have an idea how bad that is, if you have to use different shortcuts for Copy/Past, Close Window etc. for Mozilla and 4.x? If we accept that, we can also change this mapping, which was IMO a bad idea in the first place.

> No, as I said: Alt != AltGr, just like 1 on main key block != 1 on > number block. Yes, I know it isn't, that doesn't mean for Mozilla we can't pretend it isn't... Just like we make left-alt and right-alt be just alt as far as Mozilla is concerned. > E.g. you can enter chars (e.g. for the case that your keyboard doesn't > offer that char) using their char code with AltGr + CharCode on number > block. This doesn't work, if you use Alt or the number key on the main > key block. Doesn't the key composition happen at a higher level? I'm pretty sure we don't have any special code to make AltGr do what you describe. We only get what GDK gives us, and if GDK doesn't do the AltGr magic, we certainly don't, so we can just as well use AltGr when we get it (or do your arrow keys have a special meaning with AltGr?) > > get stuck halfway because one of those pages happens to be > > <http://www.google.com/> where a script gives focus to a text field. > You can disable that. IIRC, it's even off by default > I don't know other pages which do that. If there are, then either disable > JS or don't visit that pages. Chances are that they are bad anyway. http://bugzilla.mozilla.org/ does it too. And I don't want to disable that, I don't want to disable JS, I happen to think they're handy (saves me a click). > I don't care. *All* key shortcuts on Unix changed. So? Those keys only changed to be more like they are on Windows, which in most cases was changing the accelerator key from alt to ctrl. It's always been alt + left/right on Windows, so keeping unix in line with that makes sense.

> Yes, I know it isn't, that doesn't mean for Mozilla we can't pretend it > isn't... What if a Mozilla game wants to map the number block keys to other functions as the main block keys? > Just like we make left-alt and right-alt be just alt as far as Mozilla is > concerned. ?? Alt == LeftAlt, AltGr == RightAlt. > We only get what GDK gives us Sure, it was just an example. Take games as a better one. > http://bugzilla.mozilla.org/ does it too. Where? > so keeping unix in line with that makes sense. No, keeping Unix in line with Windows makes no sense at all. Users transition from 4.x Unix to Mozilla Unix, not 4.x Windows to Mozilla Unix. Why don't we do it the other way around? Why not make Windows behave like Unix? I don't care about Windows.

> Alt == LeftAlt, AltGr == RightAlt OK, I don't know, if that is universially true, but it is true for all keyboards and OSes I used.

> > Yes, I know it isn't, that doesn't mean for Mozilla we can't pretend it > > isn't... > What if a Mozilla game wants to map the number block keys to other functions > as the main block keys? > > We only get what GDK gives us > Sure, it was just an example. Take games as a better one. Assuming GDK eats the AltGr + key combo before feeding it to us, that's not a problem. If mozilla is supposed to make a distinction between left alt, right alt and AltGr, for say games, then those games have a slight problem running on certain keyboards :-) > > http://bugzilla.mozilla.org/ does it too. > Where? The textfield right next to "Show Mozilla bug no." gets focus the moment the page loads. If you've got JS enabled, of course. > > so keeping unix in line with that makes sense. > No, keeping Unix in line with Windows makes no sense at all. Users transition > from 4.x Unix to Mozilla Unix, not 4.x Windows to Mozilla Unix. So isn't it nice that we keep the alt + left/right accelerators? Oh, right, you don't like them. Funny, I do. > Why don't we do it the other way around? Why not make Windows behave > like Unix? I don't care about Windows. Uh huh. So, let's throw away the menu access key users have been begging for? No worries, there's another bug out there requesting alt to become the default accelerator key, I'd say go vote for that. Btw, in that case making accel + left/right isn't quite what you want. > > Alt == LeftAlt, AltGr == RightAlt > OK, I don't know, if that is universially true, but it is true for all > keyboards and OSes I used. Funny... First time I encountered AltGr in person was with this Toshiba laptop. All other keyboards I've seen so far have two alt keys. Btw, "alt + numpad key char value" works fine under Windows, though from your description it sounds like a feature implemented of your keyboard, not of the OS (let alone of an application).

> If mozilla is supposed to make a distinction between left alt, right > alt and AltGr, for say games, Yes, it is, assuming it wants to be a platform. > then those games have a slight problem running on certain keyboards Well, then they have. *Many* (almost all?) games do this. You might be able to reconfigure them. > So isn't it nice that we keep the alt + left/right accelerators? I'm not abjecting that. I just say they should have a(n IMO) better alternative. > No worries, there's another bug out there requesting alt to become the default > accelerator key, I'd say go vote for that Where? > Btw, in that case making accel + left/right isn't quite what you want. Hm, right. Maybe we should just map all of [L|R]Ctrl, Alt and AltGr plus arrows to Back/Fw.? > Btw, "alt + numpad key char value" works fine under Windows Didn't for me (assuming you mean LeftAlt). > though from your description it sounds like a feature implemented of your > keyboard, not of the OS I don't know, but it doesn't work in all apps. IIRC, it works with gdm, but it doesn't in GNOME-Terminal, gEdit or Mozilla. Don't ask me why... How many websites (and which ones) set the cursor into a textfiled, so Ctrl+Arrow would stop working? I am not determined on Ctrl+Arrow, but a key combo, that is easy and fast to reach with one hand. E.g. Alt+0 or similar would be fine with me (but it has to be free, of course).

> > though from your description it sounds like a feature implemented of your > > keyboard, not of the OS > I don't know, but it doesn't work in all apps. IIRC, it works with gdm, but it > doesn't in GNOME-Terminal, gEdit or Mozilla. Don't ask me why... I just checked: It doesn't work in gdm either, but it does work on the console. I am not aware of any differences in that behaviour between the keyboards I used. All of them were German 102/105-key keyboards.

(Bug 55408 "Switch default Unix modifier key back to ALT") So, come up with something other than ctrl + left/right.

Oh dearie me. The distilled wisdom of Ben Bucksch: * Because Alt and AltGr might possibly be used for distinct purposes one day, by someone who writes a game for the Mozilla platform (even though AltGr is not present on some keyboards!), AltGr+Left/+Right should not be used for Back and Forward in Mozilla Navigator itself. * If people who use Mozilla on Linux want to use the keyboard to navigate, they should either disable JavaScript, or avoid visiting `bad' sites such as Raging Search <http://ragingsearch.altavista.com/>, Bugzilla <http://bugzilla.mozilla.org/>, and Google <http://www.google.com/>. If you want the best of both worlds -- the ability to use JavaScript, and the ability to navigate through and past these sites -- then don't use Linux. * In spite of the fact that the changes of most of the other Mozilla keyboard shortcuts between 4.x and this version (to make them more consistent with the Windows shortcuts) is annoying, two other hitherto-unchanged (and very commonly used) shortcuts (Back and Forward) should *also* be changed, for the purpose of making them *inconsistent* with the Windows shortcuts. Adopting some consistency with Windows, in order to cater for the hordes of Windows users who will be switching to GNU/Linux in the next few years, is not a good idea because `I don't care about Windows'. Ben, I'm having difficulty taking you seriously here. As far as I can tell, Mozilla doesn't distinguish between a `1' typed on the keyboard and a `1' typed on the numeric keypad. And I have yet to see a good reason in this bug for Mozilla to distinguish between `Alt' and `AltGr' either.

Matthew, you got me completely wrong, especially the causalities ("because"). > Because Alt and AltGr might possibly be used for distinct purposes one day, by > someone who writes a game for the Mozilla platform The "because" is wrong. I just argued that it is a bad idea to make Alt and AltGr equvivalent in *all* of Mozilla. (Note that all != most.) Same for the num keys. > AltGr+Left/+Right should not be used for Back and Forward in Mozilla Navigator > itself. I said: "Hm, right. Maybe we should just map all of [L|R]Ctrl, Alt and AltGr plus arrows to Back/Fw.?" > If people who use Mozilla on Linux want to use the keyboard to navigate, they > should either disable JavaScript, or avoid visiting `bad' sites (..or use the alternative keys.) Note that I said: "I am not determined on Ctrl+Arrow, but a key combo, that is easy and fast to reach with one hand. E.g. Alt+0 or similar would be fine with me" (but I meant Accel+0). > then don't use Linux. Ops, this bug was meant to be XP. Changing the platform fields. > for the purpose of making them *inconsistent* with the Windows shortcuts. No, this was not the *reason*. It was just a counter-*argument* to the argument "But 4.x Win uses this shortcut, so we should keep it.". My argument is this: If we are willing to change *all* shortcuts on Unix (for a good reason, given), why shouldn't exactly *this* one be the only one that is not changed, although exactly *this* really needs the change, for the reasons given in the inital description? > Adopting some consistency with Windows, in order to cater for the hordes of > Windows users who will be switching to GNU/Linux in the next few years If I argued "Let's compeletely break backwards-compatibility on the Mac, and follow the Windows standards on the Mac, in order to cater for the hordes of users who will switch to the (superiour) Mac in a few years", what would *you* say? Any objections to making *all* of Ctrl, Alt, AltGr with the arrows work? If a textfield has the focus, Ctrl won't work, but this IMO a minor problem, given that this is infrequent, and Alt[Gr] is still availale. If anybody has alternative suggestions without arrow keys, please also say them. These could be consistently using the Accel key, and not interfere with JS on webpages (unless the JS explicitly captures this key combo).

... W.r.t. hordes of people flocking from Windows to the Mac, I would say you'd need a better statistician. :-) What I suggest is that there be separate keys (as far as Mozilla is concerned) for left-Alt and right-Alt, in case game developers or whoever want to use them. But apps in the Mozilla suite itself should use a general `alt' key, which covers both the Alt keys at once -- so every single shortcut which uses Alt doesn't have to go through hoops listening for both left-Alt and right-Alt. (The same could be done for left/right {Control/Command}, and for Return/Enter.) Then Back and Forward can use the general alt modifier rather than the specific left-Alt modifier. Ok?

> But apps in the Mozilla suite itself should use a general `alt' key, which > covers both the Alt keys at once Yes, that makes sense. > Then Back and Forward can use the general alt modifier rather than the > specific left-Alt modifier. Ok? Sure. I'd stil prefer, for consistency, if you'd aloow map ctrl+arrows to back/fw., but that's not a requirement to fix this bug.

Hooray for when users can specify their own mapping!

lol, but I think, I have to destroy your hopes: We'd have the very same discussion about the default bindings then :).

It would be nice if the XBL key binding syntax were flexible enough to allow specifying various combinations of keys, like Alt || AltGR, accel || accel+Shift. Until then, we're stuck adding multiple copies of keybindings (like having to specify both accel-+ and accel-shift-+) in such cases. So it sounds like we need: 1. To be able to use AltGr as a modifier, which I don't believe XBL currently allows (it has a fixed list of modifiers, shift, ctrl, alt, and meta), and 2. to duplicate the alt-left and alt-right key bindings to add alt-gr bindings (and ensure that this doesn't interfere with typing the international characters that AltGr is used for).

Also see bug 47079, marking this depend on that.

this bug is a mess. agree with thread that says we should fix the left/right alt problem. I vote to summarize this & start over? If progress is happening then keep this here.

there's nothing substantive before pargraph two of mpt 2000-10-26 05:59. Basically. We could have xbl: [shift, ctrl, accel, alt, meta], [shiftL, shiftR, ctrlL, ctrlR, altL, altR, accelL, accelR, metaL, metaR]. Normal binding apps would use the first class. Apps that need to be picky would use the other class. If people object to the naming of l and r, they should speak somewhere [I know they will speak].

> altL, altR, ... altGr, ...

excuse me for having read one extremely long report and still having no clue what a G is. do you want altGl, altGr? Please explain what G is.

"AltGr" is what stands on my right Alt key. It is a "special" Alt key. Don't ask me. IIRC, somebody said he had all of AltL, AltR and AlGr, so it seems like AltR != AltGr (unlike my claim early in this bug). For details, please look in some keyboard standard references or something. "I only work here"... ;-P > do you want altGl, altGr? No.

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

FYI Alt-Gr stands for 'alt graphics'. It is used on some keyboards as a second kind of shift key to obtain things like accented characters (though its exact use varies from locale to locale). On my (UK) keyboard I have a normal 'alt' to the left of my spacebar, and an alt-gr to the right of the spacebar.

This is fixed for me now, because I can use alt-gr with back and forwards arrows.

I can't. Mozilla build from 2001-05-06, Linux, Alt is Accel, German keyboard.

Mass move to jaggernaut@netscape.com

Changing the modifier from alt to control is not a viable fix, because of textareas and backward compatibility. We don't see enough need to fix this, so if you want it, go for it. ->mozilla@bucksch.org

trudelle wrote: > Changing the modifier from alt to control is not a viable fix, because of > textareas and backward compatibility. Akkana wrote 2000-10-26 12:51: > So it sounds like we need: > 1. To be able to use AltGr as a modifier, which I don't believe XBL currently > allows (it has a fixed list of modifiers, shift, ctrl, alt, and meta), and > 2. to duplicate the alt-left and alt-right key bindings to add alt-gr bindings > (and ensure that this doesn't interfere with typing the international > characters that AltGr is used for). trudelle wrote: > if you want it, go for it. ->mozilla@bucksch.org XBL is not my area. Back to default.

See also: bug 61439.

You can in fact customize Mozilla keybindings on your own system. See "The customizing document" http://www.mozilla.org/unix/customizing.html#keys

I'm not working for me here. I'm working to make mozilla better. This includes non-English users.

If we do this eventually, I suggest we create a keyboard configuration file for one-handed keyboard use in general. Such an overlay would make all the browser features more convenient, by utilizing unmodified alphanumeric keys the way Opera and Lynx do. Would anyone object if I turn this bug into a general "Create keyboarding overlay for one-handed typists" bug?

Yes, because it is about a very specific issue, which I believe should be solved in the default installation. Nevertheless, I would appreciate a *new* tracking bug about your suggestion.

okay, i filed bug 95307 for a keyboarding overlay for one-handed typists.

On Windows, AltGr is actually simulated using Ctrl+Alt, for instance I can type AltGr+` to get ¦, or I can type Ctrl+Alt+` and I still get ¦. Except that because of bug 50255 Mozilla conveniently ignores all non-typing Ctrl+Alt+ keys.

I'd like to add my vote in for backspace and shift-backspace.

I'm using Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.7+) Gecko/20020115 and none of the AltGr/ShiftR/CtrlR+arrow or kombinations of those seem to work as shortcut for back and forward. A quick(?) fix for this would be to make AltGr+arrow key equal to Alt+arrow key. AltGr+arrow key isn't used anywhere AFAIK. Another possibility would be use some special keys like F7/F8 or F1/F2. Are F3/F4 taken already? However, I'd suggest trying to find some other shortcut for this because most of the frequently needed shortcuts are in the left side of keyboard and to use any shortcut that needs an arrow key I'm forced to extra hand movement. I'd suggest Ctrl+< and Ctrl+>(+shift) because "><|" key is in between "z" and left shift in my Finnish keyboard. In general any combination with "/()[]\<>|+-" shouldn't be used because those characters can be anywhere depending on keyboard layout.

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

-> Akkana

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

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

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

This belongs in a 3rd party extension. Or use the keyconfig extension which lets you design on your own shortcuts.

Is there any current specific use on any platform for the Alt Gr[aphics] key in the core? If not, I would urge the reconsideration of the closing of this bug. Allowing one-handed navigation would be a significant accessibility improvement.