13168 - Implement more platform-specific keybindings (sparc help key, mac help key, windows menu key, etc.)

Status: RESOLVED WONTFIX

(Core :: DOM: UI Events & Focus Handling, enhancement, P3)

Description

[Roland Mainz]

Pressing the "help"-button on a Solaris sparc keyboard is a nop.
I think we should bind a function here, like "open new window with the
help-TOC"...

Same for F1 on the MS-Win??XX-Platforms...

Comment 1

[rubydoo123]

what's the status of this bug? Which milestone is this slotted for?

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Moving to UE/UI.  other is no longer the place for lost bugs.

Comment 3

[Roland Mainz]

Changing the OS to "all", because the "help" key is also available on SPARC
Linux (the OS doesn't change the hardware =:-)

----

The SPARC keyboard has a lot of more special keys:
- "Print Screen" --> should work like mozilla's "print..." menu
- "Stop" --> Stop loading
- "Again" --> Reload (??)
- "Front" --> ?? (maybe used by the window manager)
- "Open" --> ?? (maybe a short menu opens which asks what to open (message, www
etc.)
- "Find" --> should work like "Find..." menu
- "Again" --> ??
- "Undo" --> (editor UNDO ??)
- "Copy"/"Paste"/"Cut" --> [ no comment :-) ]

Comment 4

[shuang (gone)]

german, should we have a solution for solaris as well, or this is not something
on your list?

Comment 5

[leger]

Resetting QA Contact.

Comment 6

[german]

moving to m16 and assigning to myself

Comment 7

[german]

BTW, most Mac keyboards also have a help key and F1 is used often as help on
Win32...cc'ing vera who is responsible for instructional media/help etc.

Comment 8

[german]

In the interest of shipping timely we may not be able to do these SUN specific
fine-tunings, although if we can it would be great polish. Definitely after
beta1. Forwarding to Don, to see about cost...

Comment 9

[leger]

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

Comment 10

[Eli Goldberg]

Moving out of UI: Design Feedback.

Comment 11

[Akkana Peck]

My understanding is that XBL (XUL, too?  Hyatt?) key bindings will be able to be
specified as part of the skin, so one solution to this bug will be to make a
Sun-specific skin which adds the necessary keys.  That's assuming that the keys
involved generate valid unique events in our key event model; someone working on
a Sun should test this asap and file a bug on it if they don't.  (Please cc me
on that bug, if any; I might be able to fix it or at least help someone else
with the fix.)  Try walking through InitKeyPressEvent in nsGtkEventHandler.cpp
on a Sun to see what keycodes are being generated.

Comment 12

[Roland Mainz]

Seems my reply to akkana's newsgroup article got lost ;-(
Here it is...
-- snip --

> Perhaps the current solution is to make these extra bindings part of a
> vendor-specific skin?

AFAIK skins should be portable between platforms (at least the Unix ones :-) - a
vendor-specific skin would wipe-out portability ;-( See below...

----


> -------- Original Message --------
> From: Masaki Katakai - Sun Microsystems <[e-mail]>
> Subject: How to support vendor specific keybinding
> Resent-From: [e-mail]
> To: [e-mail], [e-mail]
> CC: [e-mail]
>
> I'd like to know how to support *vendor* specific keys in XUL,
> for example, Copy, Paste and Cut individual keys on Sun keyboard.
> Alt+c, Alt+v and Alt+x are assigned to the copy, paste and cut
> commands on Unix platform, but I'd like to assign the Copy, Paste
> and Cut keys additionally.
>
> I verified the VKs - VK_F20(Cut), VK_F16(Copy) and VK_F18(Paste)
> can be used in XUL (see the patch of attachment) and it works
> fine on my environment.
>
> ...
>
> My questions are,

...

>   - What is the right approach to add the *vendor* specific keybinding?
>    I don't think it's acceptable to modify platform*Bindings.xul
>    directly in xpfe/global/resources/content/unix. Those are generic
>    for Unix platform.

There isn't the _one_ Unix platform, there are many Unix-platform.
We should think about a general way to handle such vendor-specific things in
XUL, see below...


> So tell me which files should be added/modified
>    in Mozilla tree.

What about a #include-like scheme ?
First the unix-specific things are "included" (is there such a thing like
#include <> in XUL
??), then the platform-specific.
Naming of the file can be done by "vnd.`uname -s`-`uname -p`", which is
"vnd.SunOS-sparc" in
the case of the Solaris SPARC machines ("vnd." = vendor - as used in MIME-types
for
vendor-specific types...).

Comments ?
-- snip --

Comment 13

[Akkana Peck]

People or companies can make skins to do anything they want.  There's nothing
wrong with a vendor writing their own vendor-specific skin, which might or might
not work on other platforms depending on whether the platforms in question have
the keys referenced by the skin.

Comment 14

[Roland Mainz]

Agreed. But on the other side it's awfull the loose the special keys only if
someone switched the skins. 
And there's still the issue of portability. What about an application which is
Mozilla/XUL-based, created on the Linux platform - but doesn't use the "extra"
features of the Sun/SPARC platform... ;-(
It would be better to find a solution which is "global" for the whole XP toolkit
- and not for a single skin...

Comment 15

[Masaki Katakai]

Hi Akkana and Roland,



Yes, it's possible for vendor to touch the XUL files and modify them for

support of vendor-specific things in vendor's own source tree after the

Mozilla's source tree is freezed. It means that users who will get Mozilla

binaries and source codes from Mozilla.org won't be able to use the

vendor's updates.



Of course, I don't mean everything needs to be in Mozilla tree.

For example, we don't have to care the case vendor wants to change

the default homepage to the vendor's URL. However, the common thing

for operation, such as key binding, can be in Mozilla, I think.



 > What about a #include-like scheme ?



It's a good idea. Mozilla can switch the keybinding for proper

platform at runtime. However, I'm sorry I don't know XUL well

so I'm not sure it's right solution or not. It will much require

XUL changes.



How about using #include or #ifdef at build time, not at runtime.

When the build platform is for Sun, the install script will install

sun-specific file or include something if it exists then install as

the one file. It will require just changing the build script and will

not affect the current XUL scheme.

Comment 16

[don]

Move this to the future ...

Comment 17

[timeless]

As noted, hardware varies.  We probably should have a separate keybindings file
so that users with one type of keyboard can use a confused browser.  Examples:
win32 using usb mac keyboard (or a cirque keyboard that happens to have mac+win
keys); win32 x11 running mozilla from linux via ssh (or some other DISPLAY
approach, I'm lazy so I use ssh); mac os x using an x11 app with pc usb keyboard
running solaris mozilla via ssh...

Reporter, pc's have a printscreen key but it is used in windows for screen
captures.  [iirc Macs use cmd-opt-3] IMO mapping the print screen key to print
is undesirable.

don this bug has real dependencies, which do not want to be futured. Request
reconsideration or reassignment.

Subject and Bug focus changed. Someone, needs to come up with a /base/ list of
vkeys or whatever so that a keybinding file can map an arbitrary key combination
to an arbitrary action.  If mail has a sendmail key and wants to allow people to
change it then although that won't be on the list of general keys, the user 
editable file that does keymappings should be able to set it.

Currently xul keybindings are often done in xul. Things like Undo and Copy.  If
xul is the right language to do them in, then it should be a separate overlay
file, and there needs to be a mechanism to include client key bindings. I don't
think xul inclusion/overlay will work, partially because I like the idea of
being able to run an app, and then change where I view it (VNC/mstsc/...).  I
think a prefs.js style file would work better. Especially if the user could then
run the script (chrome activation) to do it.

***This is an RFE*** this is something architectural that needs to be fixed
before architecture freezes, and I would like it to be done before beta3.
Resetting priority as bug has changed its spots.

As I stated, the client side really can't be determined at build time. This
should be changable based on the client or the user's description of the client.

My manager points to modmap or xmodmap (I think that's the name I don't play
with those files)

Although I am unfamiliar w/ our IME support, I think the approach I discussed
would be useful, example:

js.keymap.set(iVK_HELP,vk_sparchelp); //Help binding.
js.keymap.modifier.set(iVKM_TILDE,"~"); //~ alone will now do nothing
// <space> after ~ will generate a ~
js.keymap.tilde.add("n"); // typing ~n will generate the ñ
js.keymap.modifier.set(iVKM_CANCEL,VK_ESCAPE);
js.keymap.modifier.set(iVKM_ACCENT,"'");//' alone will now do nothing
var vowels="aeiou";
js.keymap.accent.add(vowels); // for 'a'e'i'o'u
js.keymap.modifier.set(iVKM_GRAVE,"`");
js.keymap.grave.add(vowels); // for `a`e`i`o`u
js.keymap.modifier.set(iVK_ABORT, VK_SPACE); // this is the default. You could
use VK_BACKSPACE or something else...
//</js> I used ' ` ~ but VK_ should be used.
If a user wants to remap a key (Sparc Escape) to some other character (`~) we
should give the user a way to do this and the mechanism I briefly considered
would support that.

Comment 18

[Paul Chen]

Marking nsbeta3+ and reassigning to pchen

Comment 19

[johng]

nav triage team:
nsbeta3-
keyboard shortcuts is an area that is falling off our list of priorities, but is
also a great candidate for mozilla help.  Adding keyword help wanted.

Comment 20

[sairuh (rarely reading bugmail)]

over to me, la la...

Comment 21

[Dan Rosen]

hey, akkana, this is right up your alley. seems like these could just be thrown
into the xbl bindings (*htmlbindings.xml) assuming we know about
VK_WEIRD_SPARC_KEYS.

Comment 22

[Dan Rosen]

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

Comment 23

[rubydoo123]

setting to future

Comment 24

[Dan Rosen]

Nominating RTM (based on ease of implementation), fixing summary to make sense.

Comment 25

[sairuh (rarely reading bugmail)]

clearing status to put this up for rtm nomination.

Comment 26

[rubydoo123]

setting to rtm+

Comment 27

[Akkana Peck]

Note that this opens up a can of worms -- we would need to make key symbols in
our XP event model for these platform-specific keys, then implement them in the
gtk event listener, and it can only be tested on a Sun (which I don't have --
I've been trying for the last 36 hours to get a branch build on our old server,
and still haven't succeeded).  Do we really want to make these changes this late
in the game?  If so, I suggest we'd need some help from Sun.

Comment 28

[rubydoo123]

then this is clearly not an rtm candidate, setting to rtm-

Comment 29

[timeless]

Just creating objects and sample implementations would be useful.

I'll probably end up writing the solaris items, but if you wrote the Help item 
and made the following:
win32/linux: f1 -> Help {mozilla: opens release notes in a new window}
macos: Help key -> Help {mozilla: opens release notes in a new window}
Then I can worry about getting the solaris help key's signal (assuming it's 
feasable).

Similarly, at one point escape was a very special case, I don't remember if it 
is in the new world. If it isn't then I shouldn't have any trouble, assuming 
HCI said it's ok (I have 4 keys i'm allowed to bind, Sparc Help is not one of 
them, so I'd have to ask for approval from HCI -- which would probably not 
happen by PR3 unless that key is a priority).

Clobbering Beppe. Just make your architecture friendly to sun (me) and win 
(me).

Subject should probably be changed to:~ create reasonable observers that people 
could easily bind keys to on platforms of their choosing.

Comment 30

[Dan Rosen]

putting back beppe's rtm-.

timeless: you shouldn't be messing with these keywords, since doing that means
you're basically assigning netscape employees (akkana in this case) work which
neither we nor our managers want us doing.

you're more than welcome to work on it, however -- i'd personally like to see
this get done at some point. if sun doesn't want you binding the help key,
though, that makes me grumble as to whether we should break this bug up into
things that *actually* are intended to be done... the original bug report is
specifically about the solaris help button... :P

Comment 31

[rubydoo123]

moving to future

Comment 32

[Akkana Peck]

Giving this to timeless.  It's mostly a policy decision anyway, and I can't do
much about that, though I'm happy to review or help get changes in or whatever.

Comment 33

[timeless]

accepting and setting milestone.

Comment 34

[Jesse Ruderman]

Adding dependencies:
- bug 48322 sparc keys
- bug 36665 windows context-menu key

Comment 35

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 36

[Akkana Peck]

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

Comment 37

[Sergi]

http://www.mozilla.org/unix/customizing.html#keys

This URL contain info how to change platform specific bindings.
I propose to close this bug because it's not browser level but user
configuration level. See 85859, for example.

Comment 38

[Akkana Peck]

This bug is for key events that we can't represent because they're keys that
only exist on certain platforms (see the list in the summary).  It has nothing
to do with being able to make custom key bindings.

Comment 39

[Akkana Peck]

The DOM2 spec doesn't have these keys yet:
http://www.w3.org/TR/1999/WD-DOM-Level-2-19990719/events.html#Level2-Events-UIEvent

Maybe if we're lucky, the DOM3 spec will give us more help.

Sun has been using otherwise-unused function keys for some of its
platform-specific keys, but that doesn't seem like a good model for the windows
keys.

See also bug 154207, on updating our key event model to DOM2 or DOM3 specs.

Comment 40

[shwag]

Akkana:  How is this bug a policy decision?  Isn't it simply a matter of giving
the end user the expected behavior on platforms that moz has already decided to
supporting?

Comment 41

[Akkana Peck]

See comments 27,  and 38.  It would be a policy decision to write our own set of
key event symbols for keys that the DOM model doesn't support, and to decide
what set of keys should be covered by that model (should it include every key
that has ever appeared on any hardware that mozilla runs on?  Or just some
subset?)  It would be nice if we had some clue whether the W3C was ever going to
support these keys.  It's also a policy decision to decide to have
vendor-specific skins instead of portable ones (comment 12).

Comment 42

[Jerome Lacoste]

Didn't 229438 (fixed not so long ago) partially address that one?
Or am I completely wrong?

Comment 43

[David Perry]

I was looking at making an extension that would address/workaround blocked bug
66519.  It would be a simple onkeypress handler for the window that would watch
for special keys (the examples given in 66519 include Back, Forward, Stop, etc.
keys on "internet" keyboards) and do interesting things when it saw them.

Unfortunately, I don't see anything in the keypress event that tells me which
special key was pressed!  which, detail, keyCode, charCode, all are zero.  Is
there some event property I'm missing?  Or does this bug exist (at least in
part) because of the problem I'm seeing?

(Note that, because I'm just writing an extension, I'm not too concerned with
doing it Right(tm) and having keys named after DOM_VK_ constants; a magic
decimal number is fine for my purposes.  Even so, I don't know where to get that
out of the event object.)

Comment 44

[simon.hetzer]

Would it be possible to add cut/copy/paste to XF86Cut/XF86Copy/XF86Paste/Undo or SunCut/SunCopy/SunPaste/Undo keys additionally to F14/F16/F18/F20, because that's what the keys send when connected to Linux?

Unfortunately, the key events all map to "0". So I guess there is no way to "manually" map them by editing the platformHTMLBindings file? So could at least the keycodes be made available?

Also, the decision for F11 remap is based on the "IS_XSUN_XSERVER" macro, which makes it impractical to emulate the Solaris keyboard layout on Linux (as it would mess up F11&F12 keys).

Thanks for the consideration!

Comment 45

[Sylvestre Ledru [:Sylvestre]]

No longer a thing

Comment 46

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/72336e9a62aa
[fenix] For https://github.com/mozilla-mobile/fenix/issues/13168 - Removed the close button from history navigation bar