(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.
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?
Patch that adds a call to a sniffer 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. ***
Component: Keyboard: Navigation → User events and focus handling
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.