Currently mozilla provides the same keybindings on every platform it runs on. While this provides a consistent interface across platforms, it also means that it doesn't mesh nicely from a UI point of view with other applications on the platform. It also means that mozilla acts differently at a muscle-memory level than Netscape 4.x. Problems from a unix point of view: * Menu keybindings are bound to Control-whatever, while Netscape 4.x uses Alt-whatever. * Text entry widgets don't have the usual emacs keybindings like Netscape 4.x, but instead have some strange set of binding I have yet to determine. While I can only speak from a unix point of view, I'm sure that MacOS and Windows users have similiar expectations regarding compliance with standard keybindings for their platform. Mozilla should switch keybindings depending upon which platform it is running on to match the expected standard set. A preference for overriding this default choice may also prove useful.

Accepting and would like to work on this for M12. Yes, MacOS has some platform-specific keybindings as well, but fewer of them.

Talked to Mike; there are some hitches in the implementation of the selection interface to move the cursor around from JS. He's working on the problem, I've offered to help if I can. Marking a dependency.

Putting on PDT+ radar.

bumping up priority since it is a PDT+

linking to PDT+ tracking bug 12658

Additionally, keybindings need to be localizable.

this has been investigated and akkana has an idea on how to resolve this one but, this one can't be worked on until the dependencies are resolved. She may or may not need assistance from saari, mjudge, brade and hyatt.

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

In a couple of cases I hope a union could be done - for example I don't see any reason why Ctrl-A and Ctrl-E in a text field couldn't work the same on Windows and Mac as they do in Unix.

You bet. The lack of these bindings has been the main reason I avoided using our past client on Windows any more than necessary. Since these will be done in XUL, the user will eventually be able to substitute in whatever set of key bindings he prefers, and those of us who want the Unix/emacs bindings can have them on all platforms.

11818 (the renaming of the xul key) is in, so now the main impediment is getting the APIs for moving the selection around, 18046, which in turn has been waiting for 19981. Meanwhile, I'll be working on things like getting the platform overlays loaded (they don't seem to be doing anything now) since that's where the platform specific keybindings will live.

talked with Trudelle to see if saari could set 19981 as a top priority, Trudelle will talk with saari and see what it will ential to resolve 19981, and they will assign a fix by date. Once the fix by date is set on 19981, then mjudge can set a fix by date on 18046. When 18046 gets a fix by date, then this bug can have a fix by date. Akkana, in a perfect world -- how long do you think it will take to resolve this bug when 19981 and 18046 are resolved?

There's one other unsolved issue: platformGlobalOverlay.xul doesn't seem to be loaded, or at least its keyset doesn't merge in with the editor default keyset. I'm talking to waterson and saari to find out what needs to be done there; can't give a good estimate until I get an answer for that. Once that's solved, and the API for 18046 is in place, it's just a matter of writing some xul and js; a few days. I'll guess a week for the whole thing (helping out with the implementations for 18046, writing editor APIs, writing the xul and testing everything).

Strike that last remark. I talked to saari and waterson and they showed me where I was going wrong, and the problem is solved and the platform overlays are being loaded just fine. So it'll probably only take a few days (allow 2-3) for implementing and testing once the selection controller is working. I'll be working on the editor-specific APIs in the meantime.

setting fix by date to be 3 days after 18046 fix by date.

Making progress: checked in the editor API for various delete methods, and an initial set of emacs keybindings. The only ones hooked up so far are ^D=delete and ^H=backspace; the rest still waiting on nsISelectionController.

Beth just pointed out 10642, which is clearly another API which needs to be in for this bug (I thought Home and End were included in the 18046 API, but if Mike considers them separate bugs, he knows best).

adding some extra data for the PDT team, based on coversation from today's meeting. The keybindings that aren't in the menus are things like left arrow, right arrow, up arrow, down arrow, pageup, pagedown, home, end. Users want to be able to do the following kinds of things via keybindings: * move caret to beginning of line / end of line * move caret to beginning of paragraph/end of paragraph * move caret to beginning of document/end of document * scroll document to beginning of document/end of document * move caret to next word/previous word * move caret up/down one line * delete previous/next character Akkana, can you list any other keybondings that do not have an associated menu item?

Other big ones you didn't mention are delete forward/backward character/word, and kill to end of line. Last weekend I checked in a starter set for Unix (unimplemented since we're still waiting on 18046 for the selection motion routines). See http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/unix/platformGlobalOverlay.xul for my Unix starter set. This bug isn't on the complete list, though; it's on the concept of being able to have these sorts of key bindings. Once we get a basic set working, if there are specific bindings missing, people can file bugs against them.

The keybindings in http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/unix/platf ormGlobalOverlay.xul has things like closeCmd.{label,key,accesskey} quitApplicationCmd.{label,key,accesskey} redoCmd.{label,key,accesskey} appear to come from http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/locale/unix/platfo rmGlobalOverlay.dtd Shouldn't the platformGlobalOverlay.dtd exist under some locale (e.g., "en", "de", "fr", "ja") sub-directories for localization because close, quit and redo may use different characters in German, etc.? Cc'ing Tao.

closeCmd and friend aren't part of what I put there -- they were there before. They don't appear to be working, but I didn't remove them (at least not this time around) because I assumed that someone else had plans for them. If you decide that the .dtd file should be by-locale or otherwise need modifications, please make that a separate bug since it's not related to this one. If the overall key bindings need to be localized, that's another interesting issue -- again, not this bug but a separate one. If you file one, please cc me on it if it might involve moving key binding files to a different directory structure.

cc rchen

I filed another bug report for locale issue. The # is bug 20296. This happens in the build tree not in the product.

Just another vote to please allow the opition of Emacs key bindings on all platforms. It looks like it's going that way, but I just wanted to make clear that there's lots of people that feel strongly about this. I also know Windows uses who would love to have HOME and END keys work for C-a and C-e respectively. I also like the idea of the doing the union of all platforms when there is no conflict. (e.g. Both HOME and C-a go to the beginning of the line)

Agreeing with emacs bindings vote, this should be presented as a pref to the user? Maybe a xul file you just drop in would be good enough for beta.

As of now, you can drop in the appropriate platform overlay and get the unix bindings on any platform. I.e. copy xpfe/global/resources/content/unix/platformGlobalOverlay.xul instead of win/platformGlobalOverlay.xul into dist/bin/chrome/global/content/default. Or you can edit dist/bin/chrome/global/content/default to customize your key bindings to anything you want. Eventually I'd like to make this loadable from something like ~/.mozilla/globalOverlay.xul, but that will come later.

A while ago, Hyatt and Hangus worked together to revamp the platform provider scheme: instead of having all platform providers installed in dist/, they decided to let the platform variants live in the source tree and install only the valid one to dist/. Keybinding is one obvious example of platform-specific resources. Yes, lots of UNIX users prefer emacs keybindings. We can either resort to a new package type such as "chrome/keybindings/" or a locale type variant of all packages. For localization purpose, the latter is more intuitive.

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

Another update: I've checked in the IDL files for bug 18046, with stub implementations, and I've changed the unix key bindings to point to the stub implementations. So now you'll get JS errors on the console telling you about unimplemented functions, but once the real nsISelectionController implementations for 18046 are written, the emacs bindings should magically "just work". In reality, of course, there will probably be some bugs, so I won't close this out until we have something actually working.

updating fix by date

We have implementations for 18046, and a mostly-fix for 18046, and I have updated the unix keybindings accordingly. Current state: char motion and deletion events work (^b, ^f, ^h, ^d). Things that don't work right yet: - Page, word and kill-to-end actions don't quite work yet (Mike is looking, part of bug 18046) - Editor and browser window bindings aren't hooked up yet; these only work in text fields and text areas. - focus problem (which I think hyatt is looking at?) so you have to click in the urlbar, click in the content area, click back in the url bar, then click again in the url bar to set the caret and have events get through. Ugh.

The key bindings should also be adapted for the different keyboards. On my German keyboard the Go|Back = Alt-] doesn't work (I type [AltGr]+[9] to get the ] and Alt-AltGr-9 doesn't work and isn't comfortable.) Concerning Alt vs. Ctrl under unix, I must admitt I favour ctrl because e.g. nedit uses it as well.

burnus, see bug #20296. It's also no problem to edit the keybindings, if they don't please you.

Unfortunately, with hyatt's latest fixes, the xulkey setting is no longer settable in the xul keyset; he removed my code to parse the xulkey from the keyset and hardwired it by platform (so on Unix it's hardwired to alt). Hyatt assures me that this is temporary and that it will be settable via CSS, and the menu access key (currently hardwired to alt on all platforms, which is obviously a problem on Unix) will be settable via the same mechanism. Once that's in place, it will be no problem for burnus and other users used to the Windows model to use control as their xulkey.

I'd like to use windows keybindings on unix too. I certainly hope Alt+F will select file menu as standard on both Windows, OS/2 and Unix GUIs. (I dislike the 4.x behavior).

Status update: this is mostly in for text fields/areas, but you have to click inside, outside, then twice inside the text field before the bindings are loaded. See bug 21610. Also ^K gives a JS error, but I have a fix for that awaiting review (really part of bug 18046, and see bug 21534 for a patch).

i will take this and make the overlay load synchronously.

final m12 candidates are spinnning now. moving to m13. if we fall off track and need to respin m12 for some yet unknown reason we can consider this if you get a fix in hand.

not sure but this may be in hyatts latest checkin to the trunck and picked up in the merge to the SeaMonkey_M12_BRANCH can someone check the tip and see if its working?

Nope, hyatt's checkin last night didn't fix this -- we're still not loading the platform keybinding files.

This was working as of Hyatt's checkin on Saturday. Let's hope it stays working!

verified

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

If this is fixed and verified, how come the Home and End buttons doesn't work in the browser? PgUp and PgDown works fine!

Probably because of bugs 14026 and 23401. The browser controller is all screwed up and isn't handling most keystrokes. Page up and down don't work for me either.

Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.