18033 - [DOGFOOD] platform specific keybindings

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P1)

Description

[tor]

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.

Comment 1

[Akkana Peck]

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

Comment 2

[Akkana Peck]

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.

Comment 3

[leger]

Putting on PDT+ radar.

Comment 4

[rubydoo123]

bumping up priority since it is a PDT+

Comment 5

[rubydoo123]

linking to PDT+ tracking bug 12658

Comment 6

[bobj]

Additionally, keybindings need to be localizable.

Comment 7

[rubydoo123]

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.

Comment 8

[Akkana Peck]

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

Comment 9

[Matthew Tuck [:CodeMachine]]

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.

Comment 10

[Akkana Peck]

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.

Comment 11

[Akkana Peck]

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.

Comment 12

[rubydoo123]

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?

Comment 13

[Akkana Peck]

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).

Comment 14

[Akkana Peck]

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.

Comment 15

[rubydoo123]

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

Comment 16

[Akkana Peck]

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.

Comment 17

[Akkana Peck]

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).

Comment 18

[rubydoo123]

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?

Comment 19

[Akkana Peck]

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.

Comment 20

[bobj]

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.

Comment 21

[Akkana Peck]

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.

Comment 22

[bobj]

cc rchen

Comment 23

[rchen]

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

Comment 24

[Rick Niles]

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)

Comment 25

[Chris McAfee]

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.

Comment 26

[Akkana Peck]

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.

Comment 27

[tao]

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.

Comment 28

[leger]

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

Comment 29

[Akkana Peck]

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.

Comment 30

[rubydoo123]

updating fix by date

Comment 31

[Akkana Peck]

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.

Comment 32

[Tobias Burnus]

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.

Comment 33

[Ben Bucksch (:BenB)]

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

Comment 34

[Akkana Peck]

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.

Comment 35

[Marko Macek]

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).

Comment 36

[Akkana Peck]

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).

Comment 37

[David Hyatt]

i will take this and make the overlay load synchronously.

Comment 38

[chris hofmann]

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.

Comment 39

[chris hofmann]

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?

Comment 40

[Akkana Peck]

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

Comment 41

[Akkana Peck]

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

Comment 42

[Paul MacQuiddy]

verified

Comment 43

[Akkana Peck]

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

Comment 44

[Henrik Gemal]

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

Comment 45

[Akkana Peck]

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.

Comment 46

[leger]

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