74348 - Need Mouse Button State properties

Status: NEW

(Core :: DOM: Events, enhancement, P4)

Description

[Jeff Yates]

The event object needs to keep track of the button state.  I suggest adding 
three new boolean properties, leftButton, rightButton and middleButton.  

The reason for this is that if the mouse is pressed/released outside of the 
browser you cannot keep track via script of which buttons are pressed.  Same 
thing is true if your event handler is on an element and not on the window.

This is not just a convinience, it is a neccesity for scripting.

Comment 1

[joki (gone)]

This is really more an issue for the W3C DOM standards group.  We try not to add 
too many new custom api's.

Comment 2

[Jeff Yates]

I have been discussing this topic on the W3C-Dom mailing list.  They feel it is 
up to the implementation.

If you truly think that it should wait for the W3C to come out with it in their 
recommendations, what about this:

Add an Array property to the event called mozButtons.  Each element of the 
array will contain a Boolean value indicating the state of the button button 
(true for pressed, false for not) that contains that number.

For example:  (assume a 5 button mouse)

event.mozButtons[0]  for the state of the left.
event.mozButtons[1]  for the state of the middle button.
event.mozButtons[2]  for the state of the right button.
event.mozButtons[3]  for the state of the auxiliary1 button.
event.mozButtons[4]  for the state of the auxiliary2 button.


Using this method you can cover future versions of mouse’s that have more than 
three buttons.

Jeff.

Comment 3

[Jesse Ruderman]

> The reason for this is that if the mouse is pressed/released outside of the 
> browser you cannot keep track via script of which buttons are pressed.

Scripts should not be able to tell when I press or release the mouse in another 
window.  Why would any script other than one designed to invade my privacy want 
to know when I click in another window?

Comment 4

[Jeff Yates]

> Scripts should not be able to tell when I press or release the mouse in 
> another window.  Why would any script other than one designed to invade my 
> privacy want to know when I click in another window?

I am not talking about it the way you are taking it.

Lets say you want to move a divider bar while the mouse button is being pressed 
down.  While doing so you accidentally move the mouse outside of the browser 
frame and let go of the mouse button.  When you move the mouse back into the 
frame your script still thinks the mouse button is being pressed.

I think their should be state variables that indicate the state of all buttons 
of the mouse for all mouse events (and any other events that you wish to give 
it too).

I would suggest one of two ways, an array of booleans called buttons, or a long 
integer called buttons where each bit represents a different button.  This way 
you are not limited by the number of buttons on a mouse.

The added benifit of this is that when you get a mousedown event you can easily 
check if two buttons are pressed at the same time, thus providing an 
alternate "click" routine.

Jeff.

Comment 5

[Jesse Ruderman]

I think this would be better for scripters and less likely to introduce a 
privacy hole:

- If the user mouses down inside a window and mouses up outside a window, the 
window should see the mouseup.
- If the user mouses down outside a window and mouses up inside the window, the 
window should not see the mouseup.

I think that's how it currently works for elements inside a window (eg 
textboxes).

Comment 6

[Vladimir Ermakov]

The least we can do is set the button property on mousemove events. It seems
like a pretty useful thing to know. 

Comment 7

[Vladimir Ermakov]

*** Bug 136027 has been marked as a duplicate of this bug. ***

Comment 8

[Pavol Vaskovic]

I would agree with comment 5 - that way it works for left mouse button (at least
on Windows). That was the point of Bug 136027. I was asking to unite that
behavior for all mouse buttons. I don't understand why there is this difference
between mouse buttons?! Can someone enlighten me?

Comment 9

[Vladimir Ermakov]

to default owner

Comment 10

[Vladimir Ermakov]

Just found out that what I described in Comment #7 is bug 70427

Comment 11

[Navid Zamani]

I just noted that at least under windows, a mouseup wich happens outside the
document (not even outside the window), but is related to a mousedown on an
element does not generate an event, even for the left button!

So the functionality of comment #5 is still not implemented, wich means that
even a simple cleanly working scrollbar isn't possible in Firefox 1.0!

I think this is no enhancement but a bug in a major feature (dom events),
because inside a document this works for releases outside the element, and
because it's a blocker for usable web-applications.

If no one has time, could someone maybe show me the code-fragment responsible
for this handling, so I can fix it?

Comment 12

[Karl Tomlinson (:karlt)]

(In reply to comment #3)
> > The reason for this is that if the mouse is pressed/released outside of the 
> > browser you cannot keep track via script of which buttons are pressed.
> 
> Scripts should not be able to tell when I press or release the mouse in another 
> window.  Why would any script other than one designed to invade my privacy want 
> to know when I click in another window?

I guess your concern here is that a button press on another app and a drag that happens to traverse a browser window should not inform the document of what the user is doing.  If that is the concern, then the best solution is probably to not deliver any such mouse events at all to the document.

(In reply to comment #5)
> I think this would be better for scripters and less likely to introduce a 
> privacy hole:
> 
> - If the user mouses down inside a window and mouses up outside a window, the 
> window should see the mouseup.

The mouseup event has coordinates and so would contain information about the position outside the browser where the user released the mouse button.

It would also be delivered to a position in the document that is not visible to the user, which would be confusing.

Comment 13

[Karl Tomlinson (:karlt)]

Another case where a mouseup is not sent is when dragging selected text out of
the browser.  The mousedown is sent at the start of the drag, and on X11 no
further mouse events are sent until the pointer returns (after releasing the
drag) to the browser window.  At that point the mouseout is sent but no
mouseup.  On NT the mouseout is received at completion of the drag, but
similarly no mouseup is received.

(In reply to comment #20)

> * A document in an iframe, if the button is released outside the iframe.

Actually the mouseup is received with button 1 if preventDefault() is not called.  It is received on the element that received the mousedown (not on the document), as if the default action (selection?) is capturing the mouse to the element.

BTW, bug 74348 proposes button state in mouse events and there is a little
discussion about whether a guaranteed mouseup from outside the document is an
alternative.

Comment 14

[Karl Tomlinson (:karlt)]

Sorry comment 13 was meant to be pasted into bug 544211.