Open Bug 134583 Opened 22 years ago Updated 2 years ago

no way to rebind mouse buttons

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

People

(Reporter: jwz, Unassigned)

References

Details

Attachments

(3 files)

gpm patch
308 bytes, patch
Details | Diff | Splinter Review
patch
4.58 KB, patch
Details | Diff | Splinter Review
sample munger module
2.30 KB, application/octet-stream
Details 
(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.
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
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?
> 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
I like the idea of putting duct tape over the other buttons.

Good ol' duct tape.
> 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).



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.
Can you use a variant of this?

xinput set-button-map Mouse1 1 1 1

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

-> blizzard, reassign as needed
Assignee: aaronl → blizzard
Jamie, try mapping button 2 to button 4 and button 3 to button 5 (mousewheel).
If it works, maybe that is an acceptable workaround...?
> 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).
have you tried http://hocwp.free.fr/xbindkeys/xbindkeys.html ?
supposedly it works for mice too.

I don't see how xbindkeys could possibly help.
Attached patch gpm patch — — Splinter Review 
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?
Attached patch patch — — Splinter Review 
Patch that adds a call to a sniffer module.
Attached file sample munger module — 
Sample module that will munge events properly.
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!
*** Bug 152951 has been marked as a duplicate of this bug. ***
QA Contact: bugzilla → keyboard.navigation
Component: Keyboard: Navigation → User events and focus handling

The bug assignee didn't login in Bugzilla in the last 7 months.
:hsinyi, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: blizzard → nobody
Flags: needinfo?(htsai)

I wonder if we will want to support this...

Flags: needinfo?(htsai) → needinfo?(masayuki)

The discussion is really old. I'm not sure whether this still does not work even on Linux, and the OSes which we support still don't have this kind of accessibility settings. We can do this with a pref with touching:

== Windows ==

== Linux ==

== macOS ==

However, it seems that the points setting WidgetMouseEventBase::mButton is too many especially on macOS, so, we need to centralize it first.

Flags: needinfo?(masayuki)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: