[Bug 8406] Stricter Specifications on Mouse Events Specifically primary, auxillary, and secondary default actions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=8406

--- Comment #11 from Sirisian <warcraftthreeft@sbcglobal.net> 2012-03-18 23:21:20 UTC ---
(In reply to comment #10)
> This specification generally doesn't concern itself with the envirnment of the
> user agent (e.g., whether it's windowed, full-screen, etc.). Thus, IMHO,
> attempting to specify things that should/shouldn't happen when pointing devices
> leave/enter the scope of the user agent is out of its purview. (items 3 & 4 --
> though Comment 8 made it sound like you wanted to retract these
> recommendations?)
It's been a while since I submitted this bug. I thought maybe browsers were
just taking a while to get similar functionality for this. 3 and 4 are
important for making programming easy and intuitive. Currently in most
implementations if you hold down the left (primary) mouse button on a window
then release it outside of the window it generates a mouse up which is logical
for the program to know. However, if you do the same operation with the right
or middle mouse button it differs between browsers. In Firefox no mouseup is
generated. In Chrome a mouseup is generated.

Ideally the specification should state explicitly what you wrote:
"Force mouseup messages when mouse leaves browser window".
That is if a page gets a mousedown it should always get a mouseup such that the
two are pairs. This allows a developer to intuitively handle if a user selects
to drag an object and releases off of the window among other operations where
the developer wishes to know if the user released outside of the window by
checking clientX and clientY.

This goes along with the other concept:
"Force mousedown messages before mouseup"
Firefox for instance allows you to just mousedown outside then mouse up inside
of the window. For a developer this can be unintuitive. Standardizing this now
will make future implementations much more predictable which is what this bug
report was mostly about.

> I'm happy to add (non-normative) text describing the default actions of mouseup
> with various button states, which seems useful for authors (Items 1 & 2)

Yes this is a big one. Ideally on all browsers the following should prevent a
context menu, middle mouse scroll, and mouse wheel scroll.

In many implementations releasing the right mouse button with any other mouse
buttons pressed causes a context menu to display. Calling preventDefault should
stop that. The current specification does not cover this. The non-standard
"contextmenu" event is implemented in most browsers, but this change would make
a mandatory and intuitive implementation for preventing the behavior.

The same goes for preventing the mouse scroll where a user holds the middle
mouse wheel button down and drags around or they press the button to turn on
the scroll feature. Calling preventDefault in the mouse down event should
prevent both operations. The current specification does not cover this.

The last one is when a user scrolls by rotating their middle mouse wheel. If
preventDefault is called then no scrolling action should be taken by the
implementation. (In this scenario the developer probably wants the scroll data
for their own uses). The current specification already covers this in depth so
no changes are needed.

<!doctype html>
<html>
<head>
<script type=text/javascript>
function MouseDown(event)
{
    if (event.buttons & 4 == 4)
    {
        // Middle button was pressed. Prevent the scroll operation from
starting even if the middle mouse button was pressed
        event.preventDefault();
    }
    console.log("mouseup");
}

function MouseUp(event)
{
    if (event.buttons & 2 == 2)
    {
        // Right button was released. Prevent the context menu from displaying
        event.preventDefault();
    }
    console.log("mouseup");
}

function Wheel(event)
{
    // Prevent the middle mouse wheel scroll operation
    event.preventDefault();
    console.log("wheel");
}

function Initialize()
{
    window.addEventListener("mousedown", MouseDown, false);
    window.addEventListener("mouseup", MouseUp, false);
    window.addEventListener("wheel", Wheel, false);

    for (var i = 0; i < 200; ++i)
    {
        document.body.innerHTML += i + "<br>";
    }
}
</script>
</head>
<body onLoad="Initialize()">
</body>
</html>


> Since the time this bug was filed, a new property "buttons" has been added that
> uses the "IE" bitmask approach. I believe this satisfies item 5.
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-MouseEvent-buttons

Yeah I got them to add that a while back, so that's done.

> Item 6: currently the spec does not deprecate either the "button" attribute or
> the "buttons" attribute (which is new) on MouseEvent. Given the long history
> and significant adoption of the "button" attribute, I don't believe it would be
> appropriate to indicate that it is deprecated. In fact, I like that the
> standard offers both options in this case. Depending on the specific scenario
> you may choose one or the other.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 18 March 2012 23:21:29 UTC