84868 - Mozilla doesn't support "Internet" keyboards and mice

Status: RESOLVED DUPLICATE of bug 66519

(Core :: DOM: Events, enhancement)

Description

[Brian Alliet]

Mozilla doesn't respond to any of the "Internet" keys under X/gtk (or any other
platform as far as I know). X has keysyms for these keys and Mozilla should
respond to them.

Mozilla also does not respond to the Back/Forward buttons on internet mice under
X/gtk. X generated Button 6/7 events for these buttons and mozilla should
respond to them.

Comment 1

[Brian Alliet]

Attachment: Makes mozilla generate events for these keys. Patch against 0.9

Comment 2

[R.K.Aa.]

The mouse  part of this is bug 30431 - a "helpwanted" bug.
Perhaps this is the help..resolving as new for now.
Patch kw, CC hewitt.

Comment 3

[timeless]

--- ../mozilla/widget/public/nsGUIEvent.h       Tue Apr 17 06:02:09 2001
+++ ./widget/public/nsGUIEvent.h        Thu Jun  7 16:39:38 2001
@@ -408,21 +408,29 @@
changing constants is sometimes a bad idea.

Sending to dom because the core of this is probably the dom changes.

[e-mail]: it looks like you'll have to do a Qt version of this.
[e-mail]: I'm assuming you're actively trying to resurect --motif in 
which case you'll probably want to make a motif version of this.

Comment 4

[Brian Alliet]

I didn't really want to change the constants but there wasn't enought room to
fit the additional constants in the "pattern" that was already there. I don't
really know Qt or motif which is why I only did gtk+. I was hoping this could
give someone a good start in supporting these buttons/keys on all platforms.

Comment 5

[Alec Flett]

If everyone is using the constant macros as they should be, instead of the raw
values, then there doesn't seem to be any danger of changing these
values...Qt/etc can update to recognize these events at their own discretion.

Comment 6

[Hadean Dragon]

Not that this may be helpful, but I'll write it anyway just to verify: the
Logitech iTouch keyboard keys don't work in Mozilla under Windows XP (and most
likely other ones).  I worked around it by pointing to mozilla (using iTouch's
Program links) and using a website as a command line parameter... but it opens a
new window.

Comment 7

[saari (gone)]

->bnesse to slam in the patch if it doesn't merge conflict too much. Also look
at it on win32.

Comment 8

[Roland Mainz]

What about adding support for the Sun/SPARC function keys, e.g.
"Stop", "Copy", "Cut", "Paste", "Print", "Props"(=properties), "Front", "Open",
"Find" ?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Copy/Cut/Paste are already supported....

Comment 10

[Roland Mainz]

What about the remaining ones ("Stop", "Print", "Props"(=properties), "Open",
"Find") ? Each of them can easily be mapped to a Mozilla function, like:
"Open"  --> open new window/tab (same as middle-mouse button)
"Print" --> same as "File/Print..." menu item
"Props" --> uhm... view source - or prefs ?!
"Find"  --> start "Find" dialog

Comment 11

[Boris Zbarsky [:bzbarsky]]

Let's have a separate bug on that... this patch has already been rotting for 7
months(!) now because no one seems to care to review it.  Let's get it in if it
works and is good.

bnesse, are you actually going to deal with this anytime soon?  Like the next week?

Comment 12

[timeless]

there are bugs for sparc keys, bug 36640 bug 48322 bug 103102 

Comment 13

[Roland Mainz]

Fun. bug 48322 is rotting since two years... ;-(

Comment 14

[Brian Nesse (gone)]

Boris,
As per commment 7, this was assigned to me to slam it into the tree if it didn't
merge conflict too badly. At the time this patch had already been rotting for 5
months.

After reviewing the patch and finding things like:
+              const unsigmed long DOM_VK_GOBACK         = 0xA0;
+              const unsigmed long DOM_VK_FWD            = 0xA1;
+              const unsigmed long DOM_VK_STOP           = 0xA2;
+              const unsigmed long DOM_VK_REFRESH        = 0xA3;
+              const unsigmed long DOM_VK_SEARCH         = 0xA4;
+              const unsigmed long DOM_VK_FAV            = 0xA5;

I gathered that the patch probably hadn't even been compiled, much less tested.
Also, going through the event code adding switch cases for MOUSE_SIX_XXX and
MOUSE_SEVEN_XXX didn't appear to be a particularly graceful, or flexible,
solution to this issue. Of course, I don't know enough about the event code to
know if there is a better way to do it...

Comment 15

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 37770 [details] [diff] [review]
Makes mozilla generate events for these keys. Patch against 0.9

bnesse, thanks.  That would be a review.  :)

Comment 16

[Brian Alliet]

Hi I'm the guy that made the patch on 2001-06-08.
Yes it compiled and yes it worked great. I'm sure it doesn't apply anymore. I 
don't use linux on my main desktop anymore (I use a G4 w/ OS X), so I havn't 
bothered maintaining it. I agree that it is probably not the cleanest way to do 
it, but it seemed to be the only way to do it at the time.

Comment 17

[Brian Alliet]

I just read "unsigmed long", thats what you mean. I think that may have been a 
file used to generate some of the header files or something. I really wasn't 
completelly sure what I was doing. Whatever the case, that file obviously 
wasn't being used because I know it compiled and worked.

Comment 18

[Andrew Hagen]

This appears to be a duplicate of bug 66519.

Comment 19

[Vladimir Ermakov]

duplicate

*** This bug has been marked as a duplicate of 66519 ***