Re: Pointer event behavior across windows

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