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

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

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

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 :-) ]

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

Resetting QA Contact.

moving to m16 and assigning to myself

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.

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

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

Moving out of UI: Design Feedback.

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.

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 <Masaki.Katakai@japan.sun.com> > Subject: How to support vendor specific keybinding > Resent-From: mozilla-unix@mozilla.org > To: mozilla-xpfe@mozilla.org, mozilla-unix@mozilla.org > CC: Masaki.Katakai@japan.sun.com > > 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 --

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.

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

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.

Move this to the future ...

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.

Marking nsbeta3+ and reassigning to pchen

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.

over to me, la la...

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.

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

setting to future

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

clearing status to put this up for rtm nomination.

setting to rtm+

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.

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

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.

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

moving to future

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.

accepting and setting milestone.

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

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)

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

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.

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.

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.

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?

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

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

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

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!