Wrong buttons reported in mouseup and mousemove events




DOM: Events
12 years ago
10 years ago


(Reporter: Jens Tinz, Unassigned)


({fixed1.8.1, regression, verified1.8.0.2})

1.8 Branch
fixed1.8.1, regression, verified1.8.0.2
Bug Flags:
blocking1.8.0.1 -
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [rft-dl])


(2 attachments)



12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/412 (KHTML, like Gecko) Safari/412
Build Identifier: Deer Park Alpha 1

When releasing the right mouse button, evt.button reported as 0 in the mouseup event.
(When releasing the left or middle mouse button, the correct button is reported.)

When dragging the mouse with any button pressed, evt.button is always reported as 65535.

Reproducible: Always

Actual Results:  
When releasing the right mouse button: evt.button == 0
When dragging the mouse with any button pressed: evt.button == 65535

Expected Results:  
When releasing the right mouse button: evt.button == 2
When dragging the mouse with any button pressed: evt.button should report the id of the pressed button

This is a simplified version of the code I'm using in an extension.
I have not tried to use it in a simple HTML document.

window.addEventListener("mouseup", pieOnMouseup, true);

function pieOnMouseup(evt) {
  dump("pieOnMouseup " + evt.button + "\n");

window.addEventListener("mousemove", pieOnMousemove, true);

function pieOnMousemove(evt) {
  dump("pieOnMousemove " + evt.button + "\n");

Comment 1

12 years ago
Related to Core bug 264922?
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 3

12 years ago
Created attachment 199168 [details]
Problem with event.button generated by mousemove event

Comment 4

12 years ago
There is a problem with event.button property - if object event is generated by
mousemove, event.button property returns always value 65535.

See attached example (attachment 199168 [details]).

Tested on FireFox 1.5. beta 2, WinXP

Comment 5

12 years ago

*** This bug has been marked as a duplicate of 129775 ***
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE


12 years ago
Attachment #199168 - Attachment mime type: text/plain → text/html

Comment 6

12 years ago
I'm reopening this bug to hold only the mousemove issues that regressed between 1.0 and 1.5.
Keywords: 4xp, regression
Resolution: DUPLICATE → ---


12 years ago
Ever confirmed: true
Flags: blocking1.8.0.1?

Comment 7

12 years ago
Created attachment 207522 [details] [diff] [review]
Set button to 0, NOT -1

This change to use -1 as the default should not have been done.

0 should be the value for backwards compatibility.
Get a reviewed patch landed and tested on the trunk before seeking branch approval
Flags: blocking1.8.0.1? → blocking1.8.0.1-


12 years ago
Attachment #207522 - Flags: superreview?(bzbarsky)
Attachment #207522 - Flags: review?(bzbarsky)
Comment on attachment 207522 [details] [diff] [review]
Set button to 0, NOT -1

If you've tested that this is what IE, Opera, and Safari do, I guess this is OK.  Please make sure to add an NS_WARNING here (because code really shouldn't be getting a button for this event), and make sure to move this bug to the appropriate Core product before resolving.
Attachment #207522 - Flags: superreview?(bzbarsky)
Attachment #207522 - Flags: superreview+
Attachment #207522 - Flags: review?(bzbarsky)
Attachment #207522 - Flags: review+
Assignee: nobody → events
Component: General → DOM: Events
Flags: review+
OS: MacOS X → All
Product: Firefox → Core
QA Contact: general → ian
Hardware: Macintosh → All
Version: unspecified → 1.8 Branch

Comment 10

12 years ago
Renominating. I'll land this on the trunk.

This comment in another bug helps:



This worked OK in Firefox 1.0 and does not work in Firefox 1.5 beta 2. Our
application (Kerio MailServer Webmail) relies heavily on drag'n'drop operations,
which are now completely broken in Firefox. Other browsers that we support
(MSIE, Safari) have no problem.

This is clearly a bug; we'd need huge changes to our code to work around it. I
would guess that the same problem will be faced also by other drag'n'drop
applications, it's not specific to us.

Please put back Firefox 1.0 behavior.


Also, this broke Lotus Domino Web Mail drag drop.

Basically we broke the ability to detect drag/drop using mouse move events.
Flags: blocking1.8.0.1- → blocking1.8.0.1?
Comment on attachment 207522 [details] [diff] [review]
Set button to 0, NOT -1

Yet another unspecified DOM requirement from the real world.  Paging Dr. Hickson!

Attachment #207522 - Flags: review+
Attachment #207522 - Flags: approval1.8.0.1?

Comment 12

12 years ago
Comment on attachment 207522 [details] [diff] [review]
Set button to 0, NOT -1

a-=schrep for drivers with re-nomination for  We need to bake this on the trunk a little longer (landed today) before going out on the release branch.  Expected to pick this up for
Attachment #207522 - Flags: approval1.8.0.2?
Attachment #207522 - Flags: approval1.8.0.1?
Attachment #207522 - Flags: approval1.8.0.1-


12 years ago
Flags: blocking1.8.0.1? → blocking1.8.0.1-
Blocks: 258193

Comment 13

12 years ago
Fix checked in to trunk to bake.
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED

Comment 14

12 years ago
Comment on attachment 207522 [details] [diff] [review]
Set button to 0, NOT -1

This has baked on the trunk for 45 days with no side effects.

Reasking for approval
*** Bug 327454 has been marked as a duplicate of this bug. ***
Comment on attachment 207522 [details] [diff] [review]
Set button to 0, NOT -1

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #207522 - Flags: approval1.8.0.2? → approval1.8.0.2+
Flags: blocking1.8.0.2+


12 years ago
Keywords: fixed1.8.0.2


12 years ago
Whiteboard: [rft-dl]
verified for the mouse movement only returns 0's.

tested on Firefox builds from 20060306 on Windows, Linux and Mac
Keywords: fixed1.8.0.2 → verified1.8.0.2
mkaply, can you check this into the 1.8 branch?
Flags: blocking1.8.1?


12 years ago
Keywords: fixed1.8.1
Flags: blocking1.8.1?

Comment 19

10 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/
whatever mouse button is pressed event.button = 0.
  function createmmclsr(logdiv){
    return function (e) {
      var t = document.createTextNode(e.button+" ");

  function init(elmid, logid){
    var elm = document.getElementById(elmid);
    var logdiv = document.getElementById(logid);
    var mm = createmmclsr(logdiv);
    elm.addEventListener("mousemove", mm, false);
<div style="height:200px; width:200px; border:solid 1px black" id="image"></div>
<div id="log1"></div>
  init("image", "log1");
You need to log in before you can comment on or make changes to this bug.