Open Bug 129775 Opened 23 years ago Updated 2 years ago

event "button" and "which" properties don't work during "onmousemove" events

Categories

(Core :: DOM: Events, defect, P5)

x86
Windows NT
defect

Tracking

()

People

(Reporter: doug_anderson, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file, 1 obsolete file)

From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) BuildID: 20020204 <html> <head><title>Netscape Event Object Bug</title></head> <script> <!-- var gWC = null; var gBC = null; var gWC2 = null; var gBC2 = null; function HandleMouseMove(evt) { gWC.innerHTML = evt.which; gBC.innerHTML = evt.button; } function HandleMouseDown(evt) { gWC2.innerHTML = evt.which; gBC2.innerHTML = evt.button; } function Init() { gWC = document.getElementById("wc1"); gBC = document.getElementById("bc1"); gWC2 = document.getElementById("wc2"); gBC2 = document.getElementById("bc2"); } //--> </script> <body onload="Init()" onmousemove="HandleMouseMove(event)" onmousedown="HandleMouseDown(event)"> <table border="1px" cellpadding="2px" cellspacing="0px"> <tr><td>&nbsp;</td><td>OnMouseMove</td><td>OnMouseDown</td></tr> <tr><td>event.which:</td><td id="wc1">&nbsp;</td><td id="wc2">&nbsp;</td></tr> <tr><td>event.button:</td><td id="bc1">&nbsp;</td><td id="bc2">&nbsp;</td></tr> </table> <div> <b>Problem</b><br> The event properties that are supposed to indicate the mouse button state are not set properly in the &quot;onmousemove&quot; handler. The &quot;button&quot; property isn't set to any value and the old Netscape 4.x &quot;which&quot; property is not set to the correct value.<br> The &quot;button&quot; property seems to get set properly to a value of 2 in the &quot;onmousedown&quot; handler in response to a right-click, however, it does not get set to a value of 1 in response to a left-click. </div> </body> <html> Reproducible: Always Steps to Reproduce: 1.Run the HTML file included in the description 2. 3. Actual Results: "which" and "button" properties of the event object are not set to reflect the mouse button state during "onmousemove" handlers. Expected Results: "which" should be set to 1 if the left mouse button is pressed and 3 if the right mouse button is pressed. "button" should set bit #0 when the left mouse button is pressed and should set bit #1 when the right mouse button is pressed.
Attached file reporter's testcase (obsolete) (deleted) —
just attaching what the reporter pasted inline.
->event handling
Assignee: asa → joki
Component: Browser-General → Event Handling
Keywords: testcase
QA Contact: doron → rakeshmishra
QA Contact: rakeshmishra → trix
Reporter: Is this working for you now? Using a wheel mouse I get for OnMouseDown on BuildID 2003020308 on WinXP SP1 Mouse click Left Middle Right event.which 1 2 3 event.button 0 1 2 Is this correct or not?
No response from reporter -> Marking as WFM Reopen if this is still a problem.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
I see bogus results in the testcase. Mozilla 1.7.3 and Firefox 1.0 always show which == 19 and button == 0, a recent Mozilla nightly shows which == 65536 and button == 65535. Reopening the bug...
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Assignee: joki → events
Status: UNCONFIRMED → NEW
Component: Event Handling → DOM: Events
Ever confirmed: true
QA Contact: trix → ian
It will be VERY nice, if I can get the "button" or "which" property NOT onmousedown only, but onmousemove also. I just want to know which mouse button is pressed during mousemove. I don't wanna capture mousedown to find this out, because probably the button was pressed or released OUTSIDE the current browser window. So it seems WAY necessary that, during mousemove event, "button" or "which" attributes are set to the appropriate button number.
See also bug 258193 on this issue.
What if multiple buttons are pressed during mouse move? And how does the integer field (button) indicate that no button is pressed? I think this should be wontfix -- if people need button information during mouse move events we need a new way of getting it (buttonSet), not the same way it works for click, etc.
Bug #297919 is evidently duplicite to this bug.
Bug #297919 is evidently duplicite to this bug.
*** Bug 297919 has been marked as a duplicate of this bug. ***
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.
Flags: blocking1.7.13?
Flags: blocking1.7.13? → blocking1.7.13-
As comment 6 indicates, there's no workaround to this bug. Scenario: - press mouse button (application displays "no-drop" cursor) - move mouse outside browser window - release button - move back Application will still display "no-drop" cursor, and it has no way to avoid it. The window doesn't get mouseUp, so the only remaing method would be to test for pressed button on mouseMove. This bug is quite visible to the users.
Do we have any idea what broke this?
This is very confusing. This is a bug older than: https://bugzilla.mozilla.org/show_bug.cgi?id=258193 Which actually broke things for FF 1.5...
Assignee: events → nobody
QA Contact: ian → events
Enhanced the old test case with reporting e.buttons. This value can be used as a workaround for mousemove event. Do something like that: function(evt) { var button = evt.button; if (evt.type == "mousemove" && evt.buttons) { if (evt.buttons & 0x01) button = 0; else if (evt.buttons & 0x02) button = 2; else if (evt.buttons & 0x04) button = 1; else button = 0; } console.log("Mouse button:, button); };
Attachment #88541 - Attachment is obsolete: true
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: