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

Assigned to



20 years ago
3 months ago


(Reporter: roland.mainz, Assigned: timeless)


(Depends on 1 bug, Blocks 1 bug, {arch, helpwanted, platform-parity})

Firefox Tracking Flags

(Not tracked)


(Whiteboard: SunKey)



20 years ago
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

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


20 years ago
Blocks: 15693

Comment 1

20 years ago
what's the status of this bug? Which milestone is this slotted for?
Assignee: chofmann → shuang
Component: other → UE/UI
Moving to UE/UI.  other is no longer the place for lost bugs.


20 years ago
OS: Solaris → All
Summary: Solaris SPARC'S "help" key is a NOP → Solaris SPARC'S "help" key is a NOP (and most other special keys, too...)

Comment 3

20 years ago
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
- "Find" --> should work like "Find..." menu
- "Again" --> ??
- "Undo" --> (editor UNDO ??)
- "Copy"/"Paste"/"Cut" --> [ no comment :-) ]


20 years ago
Assignee: shuang → german

Comment 4

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


20 years ago
QA Contact: leger → elig

Comment 5

20 years ago
Resetting QA Contact.


20 years ago
Priority: P3 → P4
Target Milestone: M16

Comment 6

20 years ago
moving to m16 and assigning to myself

Comment 7

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


20 years ago
Assignee: german → don

Comment 8

20 years ago
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

20 years ago
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

Comment 10

19 years ago
Moving out of UI: Design Feedback.
Component: User Interface: Design Feedback → XPApps

Comment 11

19 years ago
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

19 years ago
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 <>
> Subject: How to support vendor specific keybinding
> Resent-From:
> To:,
> CC:
> 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
vendor-specific types...).

Comments ?
-- snip --

Comment 13

19 years ago
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

19 years ago
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

19 years ago
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 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

19 years ago
Move this to the future ...
Target Milestone: M16 → Future


19 years ago
Blocks: 48322

Comment 17

19 years ago
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_ACCENT,"'");//' alone will now do nothing
var vowels="aeiou";
js.keymap.accent.add(vowels); // for 'a'e'i'o'u
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.
No longer blocks: 48322
Keywords: arch, nsbeta3, pp
Priority: P4 → P3
Hardware: Sun → All
Summary: Solaris SPARC'S "help" key is a NOP (and most other special keys, too...) → Key bindings are part of the window manager which does not relate to the browser os
Target Milestone: Future → ---

Comment 18

19 years ago
Marking nsbeta3+ and reassigning to pchen
Assignee: don → pchen
Whiteboard: [nsbeta3+]


19 years ago

Comment 19

19 years ago
nav triage team:
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.
Keywords: helpwanted
Whiteboard: [nsbeta3+] → [nsbeta3-]
over to me, la la...
Component: XP Apps → Keyboard Navigation
QA Contact: elig → sairuh

Comment 21

19 years ago
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
Assignee: pchen → akkana

Comment 22

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

Comment 23

19 years ago
setting to future
Target Milestone: --- → Future

Comment 24

19 years ago
Nominating RTM (based on ease of implementation), fixing summary to make sense.
Severity: enhancement → normal
Keywords: rtm
Summary: Key bindings are part of the window manager which does not relate to the browser os → Implement more platform-specific keybindings (sparc help key, windows menu key, etc.)
clearing status to put this up for rtm nomination.
Whiteboard: [nsbeta3-]

Comment 26

19 years ago
setting to rtm+
Whiteboard: [nsbeta3-][rtm+]
Target Milestone: Future → M19

Comment 27

19 years ago
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.
Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-]

Comment 28

19 years ago
then this is clearly not an rtm candidate, setting to rtm-
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]
Target Milestone: M19 → Future

Comment 29

19 years ago
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 

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 

Subject should probably be changed to:~ create reasonable observers that people 
could easily bind keys to on platforms of their choosing.
Whiteboard: [nsbeta3-][rtm-] → [nsbeta3-]
Target Milestone: Future → M19

Comment 30

19 years ago
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
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]

Comment 31

19 years ago
moving to future
Target Milestone: M19 → Future

Comment 32

19 years ago
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.
Assignee: akkana → timeless

Comment 33

19 years ago
accepting and setting milestone.
Keywords: nsbeta3, rtm
Whiteboard: [nsbeta3-][rtm-]
Target Milestone: Future → mozilla0.9

Comment 34

19 years ago
Adding dependencies:
- bug 48322 sparc keys
- bug 36665 windows context-menu key
Depends on: 36665, 48322
Summary: Implement more platform-specific keybindings (sparc help key, windows menu key, etc.) → Implement more platform-specific keybindings (sparc help key, mac help key, windows menu key, etc.)


18 years ago
Target Milestone: mozilla0.9 → mozilla1.0
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 
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 36

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

Comment 37

17 years ago

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

17 years ago
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.


17 years ago
Blocks: 64371

Comment 39

17 years ago
The DOM2 spec doesn't have these keys yet:

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

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


17 years ago
Blocks: 66519


17 years ago
Blocks: sunkeymeta
Whiteboard: SunKey

Comment 40

17 years ago
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

Comment 41

17 years ago
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

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

Comment 43

15 years ago
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.)
QA Contact: bugzilla → keyboard.navigation

Comment 44

9 years ago
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!
Severity: normal → enhancement
Target Milestone: mozilla1.0.1 → ---
Version: Trunk → unspecified
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.