Last Comment Bug 297919 - Wrong buttons reported in mouseup and mousemove events
: Wrong buttons reported in mouseup and mousemove events
Status: VERIFIED FIXED
[rft-dl]
: fixed1.8.1, regression, verified1.8.0.2
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: 1.8 Branch
: All All
: -- major (vote)
: ---
Assigned To: events
: Hixie (not reading bugmail)
Mentors:
: 327454 (view as bug list)
Depends on:
Blocks: 258193
  Show dependency treegraph
 
Reported: 2005-06-16 09:19 PDT by Jens Tinz
Modified: 2007-12-06 03:38 PST (History)
6 users (show)
mtschrep: blocking1.8.0.1-
dveditz: blocking1.8.0.2+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Problem with event.button generated by mousemove event (209 bytes, text/html)
2005-10-11 07:32 PDT, Miroslav Juhos
no flags Details
Set button to 0, NOT -1 (531 bytes, patch)
2006-01-04 10:56 PST, Mike Kaply [:mkaply]
brendan: review+
bzbarsky: superreview+
mtschrep: approval1.8.0.1-
dveditz: approval1.8.0.2+
Details | Diff | Splinter Review

Description Jens Tinz 2005-06-16 09:19:54 PDT
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 zug_treno 2005-06-17 06:41:28 PDT
Related to Core bug 264922?
Comment 2 Gervase Markham [:gerv] 2005-09-27 01:46:28 PDT
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 Miroslav Juhos 2005-10-11 07:32:35 PDT
Created attachment 199168 [details]
Problem with event.button generated by mousemove event
Comment 4 Miroslav Juhos 2005-10-11 07:40:55 PDT
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 Karsten Düsterloh 2005-10-12 00:54:32 PDT

*** This bug has been marked as a duplicate of 129775 ***
Comment 6 Mike Kaply [:mkaply] 2006-01-04 10:53:04 PST
I'm reopening this bug to hold only the mousemove issues that regressed between 1.0 and 1.5.
Comment 7 Mike Kaply [:mkaply] 2006-01-04 10:56:20 PST
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.
Comment 8 Daniel Veditz [:dveditz] 2006-01-06 12:44:22 PST
Get a reviewed patch landed and tested on the trunk before seeking branch approval
Comment 9 Boris Zbarsky [:bz] 2006-01-08 17:24:49 PST
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.
Comment 10 Mike Kaply [:mkaply] 2006-01-10 07:00:19 PST
Renominating. I'll land this on the trunk.

This comment in another bug helps:

https://bugzilla.mozilla.org/show_bug.cgi?id=129775#c12

--

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.
Comment 11 Brendan Eich [:brendan] 2006-01-10 08:46:31 PST
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!

/be
Comment 12 Mike Schroepfer 2006-01-10 12:21:27 PST
Comment on attachment 207522 [details] [diff] [review]
Set button to 0, NOT -1

a-=schrep for drivers with re-nomination for 1.8.0.2.  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 1.8.0.2.
Comment 13 Mike Kaply [:mkaply] 2006-01-30 09:05:06 PST
Fix checked in to trunk to bake.
Comment 14 Mike Kaply [:mkaply] 2006-02-14 17:18:55 PST
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
Comment 15 Phil Ringnalda (:philor) 2006-02-16 22:14:50 PST
*** Bug 327454 has been marked as a duplicate of this bug. ***
Comment 16 Daniel Veditz [:dveditz] 2006-02-22 12:22:16 PST
Comment on attachment 207522 [details] [diff] [review]
Set button to 0, NOT -1

approved for 1.8.0 branch, a=dveditz for drivers
Comment 17 Tracy Walker [:tracy] 2006-03-06 14:38:15 PST
verified for the mouse movement only returns 0's.

tested on Firefox builds from 20060306 on Windows, Linux and Mac
Comment 18 Doron Rosenberg (IBM) 2006-04-11 15:19:20 PDT
mkaply, can you check this into the 1.8 branch?
Comment 19 GRAy 2007-12-06 03:38:53 PST
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
whatever mouse button is pressed event.button = 0.
<html>
<head>
<script>
  function createmmclsr(logdiv){
    return function (e) {
      var t = document.createTextNode(e.button+" ");
      logdiv.appendChild(t);
    }
  }

  function init(elmid, logid){
    var elm = document.getElementById(elmid);
    var logdiv = document.getElementById(logid);
    var mm = createmmclsr(logdiv);
    elm.addEventListener("mousemove", mm, false);
  }
</script>
</head>
<body>
<div style="height:200px; width:200px; border:solid 1px black" id="image"></div>
<div id="log1"></div>
<script>
  init("image", "log1");
</script>
</body>
</html>

Note You need to log in before you can comment on or make changes to this bug.