no way to rebind mouse buttons

NEW
Assigned to

Status

()

Core
Keyboard: Navigation
16 years ago
8 years ago

People

(Reporter: Jamie Zawinski, Assigned: blizzard)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
(Guessing at the component.)

For the kiosks at DNA Lounge, I need to re-bind all three mouse
buttons to behave as button1.  You can read the rationale for
this at http://www.dnalounge.com/backstage/src/kiosk/#usability

With NS4, this is easy: I just edit the Motif resources like so:
http://www.dnalounge.com/backstage/src/kiosk/sbin/Netscape.ad

With GTK programs, this is easy: I just use $GTK_MODULES like so:
http://www.dnalounge.com/backstage/src/kiosk/sbin/onebutton.c

I'm told that there's no way to accomplish this simple task
with Mozilla.  

Please rectify.

Comment 1

16 years ago
This is probably a dup -- certainly a much wished-for feature -- but I don't
know the other bug number offhand.  Mouse events weren't included in either the
XUL key handling or the XBL key handling.  As a workaround, you could explode
the jar files and edit the JS to add mouse handlers, e.g. see contentAreaClick.js.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All

Comment 2

16 years ago
This looks like a dup of 133529, but I'm not sure. Would using a one-
button mouse be an option for the short-term?
(Reporter)

Comment 3

16 years ago
> Would using a one-button mouse be an option for the short-term?

Unfortunately, no.  There are no one-button trackballs, let alone
one-button trackballs that are both inexpensive and sufficiently
hardened that they can be bolted down in a public place and last
longer than a day when drunk people are about.  The trackballs
I found are pretty nice -- they're $20, they light up when you
press the buttons, and it's impossible to remove the ball without
taking screws out.  With most trackballs, the balls aren't really
attached, which means they'd be bouncing around the room all
night long.

Using Netscape 4.78 forevermore is a perfectly acceptable
workaround, however.  I reported this bug because this is
a showstopper for me even *trying* to use Mozilla on my
kiosks.

"you could explode the jar files and edit the JS to add
mouse handlers" sounds hard/intimidating/fragile/not-fun,
so I think I'll pass on that.
You could explode the trackballs and wire each button to send the same
electrical signal as mouse1. Does that also sound
hard/intimidating/fragile/not-fun ?

Gerv

Comment 5

16 years ago
I like the idea of putting duct tape over the other buttons.

Good ol' duct tape.
(Reporter)

Comment 6

16 years ago
> You could explode the trackballs and wire each button
> to send the same electrical signal as mouse1.

I thought about that, but it looks like it would be
pretty difficult (I'd have to solder directly on the
circuitboard, and it's pretty tight in there.)

Plus, we *do* have to replace these things every now
and then, and it's already a big hassle to get them
in and out (lots of threading of cables through tight
spaces) and I don't need to add another hour of labor
on top of that each time one breaks.

Besides which -- come on, man!  It's solvable in 
software with both GTK and Motif.  Your honor is at
stake here.  Do you want all the kids on the playground
to laugh at you because Mozilla so worthless and weak
that it requires hardware support?
blizzard, how hard would it be for us to properly support emission hooks such as
onebutton.c uses?  It looks like the reason it doesn't work as-is is that we
hook directly into the gdk mainloop for event processing (before gtk has had a
chance to run the event through the hook function).


(Assignee)

Comment 8

16 years ago
The problem is that the inner windows aren't attached to any particular widget.
 That's why the theming solution doesn't work out of the box.

Let me look into the emission hook - that's a decent idea.  It might be possible.

Comment 9

16 years ago
Can you use a variant of this?

xinput set-button-map Mouse1 1 1 1
(Reporter)

Comment 10

16 years ago
> Can you use a variant of this?
> 
> xinput set-button-map Mouse1 1 1 1

I don't know what xinput is (I have no such program)
but the very first thing I tried was:

    xmodmap -e 'pointer = 1 1 1 1 1'

which causes a BadValue in XSetPointerMapping.
Apparently the X server believes that the pointer
map must contain only 1:1 values: you can't use
it to map N buttons to <N.

Comment 11

16 years ago
-> blizzard, reassign as needed
Assignee: aaronl → blizzard

Comment 12

16 years ago
Jamie, try mapping button 2 to button 4 and button 3 to button 5 (mousewheel).
If it works, maybe that is an acceptable workaround...?

Comment 13

16 years ago
> Jamie, try mapping button 2 to button 4 and button 3 to button 5 (mousewheel).
> If it works, maybe that is an acceptable workaround...?

Not to speak for Jamie, but he needs all 3 buttons to behave as button one for
his kiosks...  Binding mid/right buttons to 4/5 would just make those two
buttons not work (or scroll the window, depending).

Comment 14

16 years ago
have you tried http://hocwp.free.fr/xbindkeys/xbindkeys.html ?
supposedly it works for mice too.
(Reporter)

Comment 15

16 years ago
I don't see how xbindkeys could possibly help.

Comment 16

16 years ago
Created attachment 84533 [details] [diff] [review]
gpm patch

Here is a small patch to add "111", "222", and "333" to the list of legal
button sequences in gpm.  The seq[] array (in gpn.c) maps the value of the -B
argument to what amounts to a button translation table.  The new entries
translate any button state (except "all up") into a single button.

With this patch, I can start gpm with...
$ gpm -t ps/2 -m /dev/mouse -B 111 -R msc
... to map all buttons to the first, and repeat in Mouse Systems speak on
/dev/gpmdata.

after changing my mouse settings in XF86Config-4 to...
Protocol "MouseSystems"
Device	 "/dev/gpmdata/"
... I was able to start X and have my three button mouse act like one of those
expensive ones from Apple.

The catch is that *sometimes* the cursor wouldn't move *at all* after starting
X.  I don't think this has anything to do with the patch.  Could have something
to do with the version of gpm I hacked vs. the version of X I'm using, 4.1.0,
or something.  In any case, once I got it to start ok, it seemed to stay ok.
still it would be *very* nice to have a way to redefine mouse buttons
(well and keyboard shortcuts) freely - similar to how it was possible with NS4.
Is there the technical possibility to do that or was this completely 
ignored when mozilla was designed?
(Assignee)

Comment 18

16 years ago
Created attachment 84683 [details] [diff] [review]
patch

Patch that adds a call to a sniffer module.
(Assignee)

Comment 19

16 years ago
Created attachment 84685 [details]
sample munger module

Sample module that will munge events properly.
(Reporter)

Comment 20

16 years ago
Ok, I worked around this Mozilla deficiency by using a hacked version of gpm to
re-map the mouse buttons before X sees them (thanks to everyone who helped with
that.)  So I have a solution for my kiosks.  But I still think it's extra, extra
silly that Mozilla has no user-accessible mouse keymap, so don't go closing this
on my account!

Comment 21

15 years ago
*** Bug 152951 has been marked as a duplicate of this bug. ***
QA Contact: bugzilla → keyboard.navigation
You need to log in before you can comment on or make changes to this bug.