Closed Bug 18033 Opened 21 years ago Closed 21 years ago

[DOGFOOD] platform specific keybindings


(SeaMonkey :: General, defect, P1)



(Not tracked)



(Reporter: tor, Assigned: akkzilla)



(Whiteboard: [PDT+] [by 12/15] [checked in, but dependent on 21610])

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.
Target Milestone: M12
Accepting and would like to work on this for M12.  Yes, MacOS has some
platform-specific keybindings as well, but fewer of them.
Depends on: 18046
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.
Whiteboard: [PDT+]
Putting on PDT+ radar.
Priority: P3 → P1
bumping up priority since it is a PDT+
Blocks: 12658
linking to PDT+ tracking bug 12658
Additionally, keybindings need to be localizable.
Whiteboard: [PDT+] → [PDT+] [by 11/26 -- if depencies are resolved]
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.
Depends on: 13378
Blocks: 18951
Whiteboard: [PDT+] [by 11/26 -- if depencies are resolved] → [PDT+] [dependent on 13378 getting resolved]
Whiteboard: [PDT+] [dependent on 13378 getting resolved] → [PDT+] [dependent on 18046 getting resolved]
Whiteboard: [PDT+] [dependent on 18046 getting resolved] → [PDT+] [dependent on 19981 and 18046 getting resolved]
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.
Whiteboard: [PDT+] [dependent on 19981 and 18046 getting resolved] → [PDT+] [by 18046 fix by date + 3 days] [dependent on 19981 and 18046 getting resolved]
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.
Blocks: 20203
Depends on: 10642
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
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
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

has things like


appear to come from

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

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
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.
Whiteboard: [PDT+] [by 18046 fix by date + 3 days] [dependent on 19981 and 18046 getting resolved] → [PDT+] [by 12/10] [dependent on 19981 and 18046 getting resolved]
*** 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.
Blocks: 20870
Whiteboard: [PDT+] [by 12/10] [dependent on 19981 and 18046 getting resolved] → [PDT+] [by 12/15] [dependent on 19981 and 18046 getting resolved]
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).
Blocks: 21564
Depends on: 21610
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).
Assignee: akkana → hyatt
i will take this and make the overlay load synchronously.
Assignee: hyatt → akkana
Whiteboard: [PDT+] [by 12/15] [dependent on 19981 and 18046 getting resolved] → [PDT+] [by 12/15] [checked in, but dependent on 21610]
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.
Blocks: 22176
Closed: 21 years ago
Resolution: --- → FIXED
This was working as of Hyatt's checkin on Saturday.  Let's hope it stays
*** 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
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
No longer blocks: 18951
No longer blocks: 20203
No longer blocks: 20870
No longer blocks: 21564
No longer blocks: 22176
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.