https://www.w3.org/Bugs/Public/show_bug.cgi?id=8406
Travis Leithead [MSFT] tra...@microsoft.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution||FIXED
--- Comment #17 from Travis Leithead [MSFT] tra...@microsoft.com 2012-04-05
23:49:26 UTC ---
(In reply to comment #16)
Someone brought up some confusion in the buttons member for MouseEvent. This
is regarding the behavior of MouseEvent with multiple devices. Not sure if
it's
possible, but could you explicitly state that the MouseEvent buttons property
represents the binary ORed result of all mouse device buttons.
As an example if a person have both a laptop trackpad and a USB mouse if they
hold both primary mouse buttons and release one the bit for the primary mouse
button will still be set.
I don't think that I'll note this in the spec. Here's why:
Most (all?) operating systems that incorporate a mouse-driven pointing device,
have only a single mouse input stack. Even if you plug in two mice or use a
mouse + trackpad, as in your example, the underlying operating system is going
to merge these inputs into one stack as best it can.
For example, when moving each of these mice, you'll notice that each mouse does
not maintain it's original position on screen relative to the last position it
was moved to. Rather, movements of each mouse are relative to the current
pointer position because their inputs are being merged.
When using the mouse buttons, a similar merging will occur. This technique (by
the way) will likely break most web-page-based state machines for tracking the
mouse... If you press down on the primary mouse button of one device the OS
will disptch a mousedown event to the system. Then if you press down on the
primary mouse button of another device, the operating system will simply
blindly (unless a specific OS handles this scenario better) dispatch another
mousedown event! The button state that is reported by the DOM event in these
cases is pretty dependent on how the OS exposes this information. When you
release one of these buttons, my guess (not having two mice to check against on
my windows-based box) is that the mouse-up event and related button are fed
into the mouse state machine, and will report that no buttons are now pressed
even though you're still holding down the other mouse button!
These type of scenarios are much better suited for multi-point input, such as
touch events, which have a different programming pattern in general. In such
scenarios, web developers will know to _expect_ simultaneous input -- happily
our fingers don't have buttons on them :-)
I'm resolving as Fixed to avoid confusing this re-activation for a different
issue with the resolution of the original issue. Please file a new bug if you
have further feedback or issues with the spec :)
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
