[D3E] background on mousemove info in IE10/11

In our last telecon we reviewed IE11's behavior related to normatively specifying the event order. A question came up about why IE was dispatching a mousemove right before the event sequence. I asked some folks internally and their response is included below.

In summary, the reason is not for any compatibility or site-compat concern, but a reflection of our implementation. I'd like to avoid having to change our implementation just to satisfy a normative requirement in the spec when it doesn't seem like these extra mousemove will make any difference to web compat. Perhaps we can add (to the normative order) that mousemove might be dispatched before/after the canonical sequence?

From: Jacob Rossi
Sent: Wednesday, October 23, 2013 2:01 PM
To: Travis Leithead; Justin Rogers
Subject: RE: Can you explain this particular stray mousemove?

[..]

As for why IE behaves this way, my second  paragraph tried to answer that. Rephrased and expanded, our mental model is that a move event *produces* over/out/enter/leave events. You can't enter an element without first having moved.

Think about a scenario where you only handle move events and not enter. If the move message that generates the enter didn't also generate a move, then you'd be losing a frame of input (and the interaction would glitch).

Does that explain it better?

From: Jacob Rossi
Sent: Tuesday, October 22, 2013 9:12 PM
To: Travis Leithead; Justin Rogers
Subject: RE: Can you explain this particular stray mousemove?

One windows message generates all of these events (WM_POINTERUPDATE on Win8+, WM_MOUSEMOVE on Win7).  Our code always fires a mousemove (or pointermove) event for these events. After firing that, we then run our "GenerateOverOut" code path that determines if the move produced a hit-test transition. That's the how.

For the why, it's mostly a simplification on our part I think. I could a model where instead of "GenerateOverOut" we "DetectOverOut" and then decide to either fire (a) mousemove/pointermove or (b) mouseover/pointerover. It's worth noting this area of the code is quite complex and prone to regressions. Since the frequency of mousemoves isn't defined, I'm not sure this will be important for interop.


From: Travis Leithead
Sent: Tuesday, October 22, 2013 6:03 PM
To: Jacob Rossi
Subject: Can you explain this particular stray mousemove?

I'm working with Gary (from Google) on DOM 3 Events, and we were looking at making the event sequence for mouse events normative. Firefox/IE agree on the order right now, except that IE fires an extra mousemove right before "enter". See test page: https://dvcs.w3.org/hg/d4e/raw-file/tip/mouse-event-test.html

[..]