[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 #12 from Travis Leithead [MSFT] <travil@microsoft.com> 2012-03-20 21:09:11 UTC ---
I'll get started on the default actions for middle/right mouse button down.
However, it is likely not to be as strong a statement as you would like,
because:
1. This specification does not define the "contextmenu" event from HTML5. Thus,
it won't be appropriate for me to exactly describe the interaction between the
mouse events and this event, though I can imply the behavior with non-normative
notes. Sames goes for the middle-button panning.
2. Not all implementations of this spec MUST have that behavior, and some user
agents may not have more than one button anyway--so it's inappropriate to use
conformance statements for these suggestions.

I do like having them in there for completeness though.


(In reply to comment #11)
> (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 )

> 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.

It is true that most browsers allow the mouseup event to be triggered in the
browser even when the mouse leaves the browser window. This concept is
implemented using a technique called "mouse capture". Mouse capture is a
formalism that this spec has avoided in the past due to some of the
complexities surrounding it. 

I think at best I could describe this behavior in the spec as a note, since
it's interesting for authors to be aware of, but lands outside the scope since
it deals with concepts of a windowing environment, and needs to account for
behavior with Iframes, and security, etc.

I don't believe that specifying the "always force mousedown messages before
mouseup" is appropriate. My first concern is that no implementation currently
does this, and so any tests for this feature would fail, and so this makes it
extremely hard to wrap up this spec, and get it to REC, which is my goal.
Second, this likely would pose a compatibility risk since OS's allow these
messages to be sent as they happen directly to browsers--browser pass them on
directly to web sites, which means that web sites already maintain somewhat
elaborate state machines to handle these cases (if they are important).
Changing this behavior to automatically inject a mousedown when an up occurs
will likely break these web-page-specific state machines. Notably, I can
imagine a mousedown handler that resets all state, then a move handler that
establishes state, and the mouseup handler that commits it. If a mousedown were
auto-injected into the page after the user had recieved numerous mousemoves,
then the state would be cleared and then committed (with no data) rather than
committing the accumulated data if no mousedown were recieved (as happens
today).

-- 
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 Tuesday, 20 March 2012 21:09:19 UTC