250143 - Ignore unassigned mouse buttons >= 8 (GTK2 event handler)

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[peterco]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040704 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

When using a mouse with more than 7 buttons, firefox generates a
left mouse button event for buttons >= 8 instead of simply ignoring
the originating button press.

Could you please include the attached patch to correct this behaviour?

I'm using a Logitech mouse (with the evdev mouse driver) which features
autoscrolling for buttons 9 and 10; it generates additional wheel button
events (4/5). While "scrolling" with these buttons, firefox adds
left button events which renders it unusable.

Reproducible: Always
Steps to Reproduce:
1. With xev (part of XFree86), check that your mouse generates
ButtonPress/ButtonRelease events with "button" >= 8.
2. View any webpage.
3. Click any of the mouse buttons generating button events >= 8.

Actual Results:  
Firefox acts as if the left mouse button (button 1) has been pressed, for
example marking text on a webpage or executing a hyperlink.

Expected Results:  
Mouse button events >= 8 should simply be ignored.

Comment 1

[peterco]

Attachment: Explicitly handle NS_MOUSE_LEFT_BUTTON_DOWN event

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 152495 [details] [diff] [review]
Explicitly handle NS_MOUSE_LEFT_BUTTON_DOWN event

Except now eventType will be undefined for anything other than 1 2 or 3 events.
 You want to set eventType to NS_EVENT_NULL with an early return I think.

Comment 3

[peterco]

Attachment: Return early on button events != 1|2|3

Does this solve the problem in a correct manner?
If I presume correctly, assigning NS_EVENT_NULL to eventType would become
redundant in this case.

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Anders Kaseorg]

Nope, this is still a problem in both Mozilla 1.7.11 and Deer Park beta 1 on
Fedora development. The scroll buttons on my MX1000 still activate any
hyperlinks that might be in their way.

Comment 6

[peterco]

Attachment: Return early on button events [^123]

Would you please reconsider this bug?

Events for mice with more than 7 logical buttons are still handled inappropriately  in both the current firefox release (v1.5.0.1) and CVS.

Comment 7

[Michael Wu [:mwu]]

Attachment: Don't send events for unknown buttons

I have a MX1000 also. :)

Comment 8

[Michael Wu [:mwu]]

Checking in widget/src/gtk2/nsWindow.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.224; previous revision: 1.223
done