W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2013

Re: Pointer event behavior across windows

From: Rick Byers <rbyers@google.com>
Date: Fri, 15 Mar 2013 21:33:23 -0400
Message-ID: <CAFUtAY-caeqBj6VwPbewmc4YJ-uNFrzfkGif5wBEVov48gF0AA@mail.gmail.com>
To: Jacob Rossi <Jacob.Rossi@microsoft.com>
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
On Fri, Mar 15, 2013 at 6:20 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

> On Fri, Mar 15, 2013 at 6:40 AM, Rick Byers <rbyers@google.com> wrote:
> >
> > Hey Jacob,
> > I'm curious about the expected behavior of pointer events across
> multiple browser windows.  I think this falls outside the domain of the
> spec (more OS behavior I guess), but I think it's still something we should
> try to make consistent across different implementations.  Do you agree?
>  Eg. there are some reasonable multi-window web application scenarios.
>
> Happy to share some Windows insights here. But yeah, it probably wouldn't
> fit in the spec (though there is already a non-normative note that
> discusses the ramification of multi-window scenarios and primary pointer
> selection).
>
> > What I see in IE10 (eg. using www.rbyers.net/eventTest.html) is that if
> I start touching one window and drag out, I get MSPointerOut as expected.
> If I drag back in to the same window I get MSPointerOver and the event
> sequence resumes, as expected.  BUT if I drag over a new window, I get no
> events at all until I lift - then I get an MSPointerOver MSPointerOut pair
> in the new window.  That seems very odd to me.
> >
> > The mouse behavior is a bit more rational.  When no buttons are down,
> you get the expected behavior (moving over a new window gives
> MSPointerOver, MSPointerMove, etc.).  When a button is down you get
> MSPointerOut on the original window, and no events on the new window (until
> the first mouse move after button up of course).
> >
> > Any advice from Microsoft on how implementations should ideally behave
> here?  With touch events this scenario was clear - there's an implicit
> capture so the original window continues to receive events even when the
> finger is outside.
>
> The behavior comes from the design of the Windows 8 input stack for
> WM_POINTER messages. It's actually not different between Mouse/Pen/Touch.
> All input messages are implicitly captured to the hit tested window, but
> only when in the "down" state (e.g. "active buttons state" in the spec). So
> mouse doesn't get captured when hovering. But it should get captured when
> you have a button down.
>

Thanks.  That makes sense, but doesn't explain the difference I was seeing
on button up between touch and mouse. Presumably the touch behavior is just
a bug?

 -Jacob
>
>
>
Received on Saturday, 16 March 2013 01:34:10 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:17:04 GMT