- From: Jacob Rossi <Jacob.Rossi@microsoft.com>
- Date: Sat, 23 Mar 2013 00:47:59 +0000
- To: Rick Byers <rbyers@google.com>
- CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
On Fri, Mar 15, 2013 at 6:33 PM, Rick Byers <rbyers@google.com> wrote: > > 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? Yeah, I believe it is a bug in our implementation.
Received on Saturday, 23 March 2013 00:49:32 UTC