Made mouseover/out/enter/leave event firing independent of corresponding PEs (#56)

mustaqahmed · RByers · commit 9500cf65ea7c · 2016-05-25T12:38:07.000-04:00
The spec currently suggests that compatibility mouse transition
events (i.e. mouseover, mouseout, mouseenter and mouseleave) should be
fired right after firing the corresponding PointerEvents, implying a 1:1
correspondence between the PointerEvents vs the compatibility
MouseEvents. This 1:1 correspondence breaks the consistency of
MouseEvent sequence itself when two or more primary pointers (of
different types) are active at the same time. For example, mouseover
events can be sent to two different targets without a mouseout
in-between, which can possibly break the UIs based on legacy
MouseEvents, e.g., by opening two menu items at the same time. (Issue

This patch fixes the problem by omitting the 1:1 correspondence
altogether. More precisely, it suggests to fire the compatibility mouse
transition events right before a pointerdown/up/move event.

In addition, this patch modifies the default actions of pointerover,
pointerout, pointerenter and pointerleave events to "none". This keeps
the spec effectively unchanged since the original default action was
"the default action of corresponding MouseEvent" but the UI Event Spec
defines those default actions as "none".
diff --git a/index.html b/index.html
@@ -357,12 +357,12 @@ <h3>The <code>buttons</code> property</h3>
 			</section>
 		</section>
 		<section>
-			<h2><dfn>The Primary Pointer</dfn></h2>
+			<h2>The <dfn>Primary Pointer</dfn></h2>
 			<div><p>In a multi-pointer (e.g. multi-touch) scenario, the <a href="#widl-PointerEvent-isPrimary"><code>isPrimary</code></a> property is used to identify a master pointer amongst the set of <a data-lt="active pointer">active pointers</a> for each pointer type.</p></div>
 			<ul>
 				<li>At any given time, there can only ever be at most one primary pointer for each pointer type.</li>
 				<li>The first pointer to become active for a particular pointer type (e.g. the first finger to touch the screen in a multi-touch interaction) becomes the primary pointer for that pointer type.</li>
-				<li>Only a primary pointer will produce <a>compatibility mouse events</a>. In the case where there are multiple <a href="#the-primary-pointer">primary pointers</a>, these pointers will all produce <a>compatibility mouse events</a>.</li>
+				<li>Only a primary pointer will produce <a>compatibility mouse events</a>. In the case where there are multiple <a data-lt="Primary Pointer">primary pointers</a>, these pointers will all produce <a>compatibility mouse events</a>.</li>
 			</ul>
 			<div class="note">Authors who desire single-pointer interaction can achieve this by ignoring non-primary pointers (however, see the note below on <a href="#multiple-primary-pointers">multiple primary pointers</a>).</p></div>
 			<div class="note" id="multiple-primary-pointers">When two or more pointer device types are being used concurrently, multiple pointers (one for each <code>pointerType</code>) are considered primary. For example, a touch contact and a mouse cursor moved simultaneously will produce pointers that are both considered primary.</div>
@@ -439,14 +439,14 @@ <h3>List of Pointer Events</h3>
 						<td>Sync</td>
 						<td>Yes</td>
 						<td>Yes</td>
-						<td>Varies:  when the pointer is primary, all default actions of <code>mouseover</code></td>
+						<td>None</td>
 					</tr>
 					<tr>
 						<td><code>pointerenter</code></td>
 						<td>Sync</td>
 						<td>No</td>
 						<td>No</td>
-						<td>Varies:  when the pointer is primary, all default actions of <code>mouseenter</code></td>
+						<td>None</td>
 					</tr>
 					<tr>
 						<td><code>pointerdown</code></td>
@@ -482,14 +482,14 @@ <h3>List of Pointer Events</h3>
 						<td>Sync</td>
 						<td>Yes</td>
 						<td>Yes</td>
-						<td>Varies:  when the pointer is primary, all default actions of <code>mouseout</code></td>
+						<td>None</td>
 					</tr>
 					<tr>
 						<td><code>pointerleave</code></td>
 						<td>Sync</td>
 						<td>No</td>
 						<td>No</td>
-						<td>Varies:  when the pointer is primary, all default actions of <code>mouseleave</code></td>
+						<td>None</td>
 					</tr>
 					<tr>
 						<td><code>gotpointercapture</code></td>
@@ -507,7 +507,7 @@ <h3>List of Pointer Events</h3>
 					</tr>
 				</tbody>
 			</table>
-		<p>In the case of the <a href="#the-primary-pointer">primary pointer</a>, these events (with the exception of <code>gotpointercapture</code>, and <code>lostpointercapture</code>) may also fire <a>compatibility mouse events</a>.</p>
+		<p>In the case of the <a>primary pointer</a>, these events (with the exception of <code>gotpointercapture</code>, and <code>lostpointercapture</code>) may also fire <a>compatibility mouse events</a>.</p>
 		</section>
 		<section>
 			<h3><dfn>The <code>pointerover</code> event</dfn></h3>
@@ -796,38 +796,44 @@ <h3>Implicit Release of Pointer Capture</h3>
 </section>
 <section>
 		<h1><dfn lt="compatibility mouse events">Compatibility Mapping with Mouse Events</dfn></h1>
-		<div><p>The vast majority of web content existing today codes only to Mouse Events. The following describes an algorithm for how a user agent MAY map generic pointer input to mouse events for compatibility with this content. </p>
-        <p>Unless otherwise noted, the target of any mapped mouse event SHOULD be the same target as the respective pointer event unless the target is no longer participating in its <code>ownerDocument</code>'s tree. In this case, the mouse event should be fired at the original target's nearest ancestor node (at the time it was removed from the tree) that still participates in its <code>ownerDocument</code>'s tree, meaning that a new event path (based on the new target node) is built for the mouse event.</p>
-		<p>Authors can prevent the production of certain compatibility mouse events by canceling the <code>pointerdown</code> event. </p>
-		<section class="note">Mouse events can only be prevented when the pointer is down.  Hovering pointers (e.g. a mouse with no buttons pressed) cannot have their mouse events prevented. And, the <code>mouseover</code>, <code>mouseout</code>, <code>mouseenter</code>, and <code>mouseleave</code> events are never prevented (even if the pointer is down).</section>
-		<p>The compatibility mapping with mouse events are an OPTIONAL feature of this specification. User agents are encouraged to support the feature for best compatibility with existing legacy content. User agents that do not support compatibility mouse events are still encouraged to support the <code>click</code> and <code>contextmenu</code> events (see the note below).</p>
+		<div><p>The vast majority of web content existing today codes only to Mouse Events. The following describes an algorithm for how a user agent MAY map generic pointer input to mouse events for compatibility with this content.</p>
+        <p>The compatibility mapping with mouse events are an OPTIONAL feature of this specification. User agents are encouraged to support the feature for best compatibility with existing legacy content. User agents that do not support compatibility mouse events are still encouraged to support the <code>click</code> and <code>contextmenu</code> events (see the note below).</p>
 		<section class="note">
 			<p>The <code>click</code> event, defined in [[DOM-LEVEL-3-EVENTS]], and the <code>contextmenu</code> event, defined in [[HTML5]], are not considered <a title="compatibility mouse events" href="#dfn-compatibility-mouse-events">compatibility mouse events</a> as they are typically tied to user interface activation and are fired from other input devices, like keyboards.</p>
 			<p>In user agents that support firing <code>click</code> and/or <code>contextmenu</code>, calling <code>preventDefault</code> during a pointer event typically does not have an effect on whether <code>click</code> and/or <code>contextmenu</code> are fired or not.  Because they are not compatibility mouse events, user agents typically fire <code>click</code> and <code>contextmenu</code> for all pointing devices, including pointers that are not primary pointers.</p>
 			<p>The relative ordering of these high-level events (<code>click</code>, <code>contextmenu</code>, <code>focus</code>, <code>blur</code>, etc.) with pointer events is undefined and varies between user agents. For example, in some user agents <code>contextmenu</code> will often follow a <code>pointerup</code>, in others it'll often precede a <code>pointerup</code> or <code>pointercancel</code>, and in some situations it may be fired without any corresponding pointer event (such as a keyboard shortcut).</p>
 		</section>
+		<p>Unless otherwise noted, the target of any mapped mouse event SHOULD be the same target as the respective pointer event unless the target is no longer participating in its <code>ownerDocument</code>'s tree. In this case, the mouse event should be fired at the original target's nearest ancestor node (at the time it was removed from the tree) that still participates in its <code>ownerDocument</code>'s tree, meaning that a new event path (based on the new target node) is built for the mouse event.</p>
+		<p>Authors can prevent the production of certain compatibility mouse events by canceling the <code>pointerdown</code> event. </p>
+		<section class="note">Mouse events can only be prevented when the pointer is down.  Hovering pointers (e.g. a mouse with no buttons pressed) cannot have their mouse events prevented. And, the <code>mouseover</code>, <code>mouseout</code>, <code>mouseenter</code>, and <code>mouseleave</code> events are never prevented (even if the pointer is down).</section>
 		</div>
+		<section>
+			<h2><dfn>Tracking the effective position of the legacy mouse pointer</dfn></h2>
+			<div>
+			<p>While only the <a data-lt="Primary Pointer">primary pointers</a> can produce compatibility mouse events, <a href="#multiple-primary-pointers">multiple primary pointers</a> can be active simultaneously, each producing its own compatibility mouse events.  Since all these compatibility events would appear to MouseEvent code to be coming from a single mouse device, user agents are encouraged to guarantee that the compatibility mouse events are consistent from a single device perspective.  For mouse transition events (i.e., <code>mouseover</code>, <code>mouseout</code>, <code>mouseenter</code> and <code>mouseleave</code>), this means the entry/exit state for every event target is valid as implied by [[!DOM-LEVEL-3-EVENTS]].  Users agents SHOULD guarantee this by maintaining the <dfn>effective position of the legacy mouse pointer</dfn> in the document as follows.</p>
+			<p>Right before firing a <code>pointerdown</code>, <code>pointerup</code> or <code>pointermove</code> event, or a <code>pointerleave</code> event at the <code>window</code>, the user agent SHOULD run the following steps:</p>
+			<ol>
+				<li>Let <code>T</code> be the target of the <code>pointerdown</code>, <code>pointerup</code> or <code>pointermove</code> event being dispatched. For the <code>pointerleave</code> event, unset <code>T</code>.</li>
+				<li>If <code>T</code> and current <a data-lt="effective position of the legacy mouse pointer">effective legacy mouse pointer position</a> are both unset or they are uqual, terminate these steps.</li>
+				<li>Dispatch <code>mouseover</code>, <code>mouseout</code>, <code>mouseenter</code> and <code>mouseleave</code> events as per [[!DOM-LEVEL-3-EVENTS]] for a mouse moving from the current <a data-lt="effective position of the legacy mouse pointer">effective legacy mouse pointer position</a> to <code>T</code>. Consider an unset value of either current <a data-lt="effective position of the legacy mouse pointer">effective legacy mouse pointer position</a> or <code>T</code> as an out-of-window mouse position.</li>
+				<li>Set <a data-lt="effective position of the legacy mouse pointer">effective legacy mouse pointer position</a> to <code>T</code>.</li>
+			</ol>
+			</div>
+		</section>
 		<section>
 			<h2>Mapping for devices that support hover</h2>
-			<div>Whenever a user agent is to dispatch a pointer event for a device that supports hover, it MAY run the following steps:
+			<div>Whenever a user agent is to dispatch a pointer event for a device that supports hover, it SHOULD run the following steps:
 				<ol>
 					<li>If the <code>isPrimary</code> property for the pointer event to be dispatched is <code>false</code> then dispatch the pointer event and terminate these steps.</li>
+					<li>If the pointer event to be is dispatched is <code>pointerdown</code>, <code>pointerup</code> or <code>pointermove</code>, dispatch compatibility mouse transition events as described in <a>Tracking the effective position of the legacy mouse pointer</a>.</li>
 					<li>Dispatch the pointer event.</li>
 					<li>If the pointer event dispatched was <code>pointerdown</code> and the event was <a data-lt="canceled event">canceled</a>, then set the <i>PREVENT MOUSE EVENT</i> flag for this <code>pointerType</code>.</li>
-					<li>If the pointer event dispatched was: 
-						<ul>
-							<li><code>pointerover</code>, then fire a <code>mouseover</code> event.</li>
-							<li><code>pointerout</code>, then fire a <code>mouseout</code> event.</li>
-							<li><code>pointerenter</code>, then fire a <code>mouseenter</code> event.</li>
-							<li><code>pointerleave</code>, then fire a <code>mouseleave</code> event.</li>
-						</ul>
-                    </li>
 					<li>If the <i>PREVENT MOUSE EVENT</i> flag is <b>not</b> set for this <code>pointerType</code> and the pointer event dispatched was:
 						<ul>
 							<li><code>pointerdown</code>, then fire a <code>mousedown</code> event.</li>
 							<li><code>pointermove</code>, then fire a <code>mousemove</code> event.</li>
 							<li><code>pointerup</code>, then fire a <code>mouseup</code> event.</li>
-							<li><code>pointercancel</code>, then fire a <code>mouseup</code> event at the <b><code>window</code>.</b></li>
+							<li><code>pointercancel</code>, then fire a <code>mouseup</code> event at the <code>window</code>.</li>
 						</ul>
 					</li>
 					<li>If the pointer event dispatched was <code>pointerup</code> or <code>pointercancel</code>, clear the <i>PREVENT MOUSE EVENT</i> flag for this <code>pointerType</code>.</li>
@@ -843,26 +849,19 @@ <h2>Mapping for devices that do not support hover</h2>
 			</ul>
 			<section class="note">Hover is sometimes used to toggle the visibility of UI elements in content designed for mouse (e.g. "hover menus"). This content is often incompatible with <a href=#mapping-for-devices-that-do-not-support-hover>devices that do not support hover</a>. This specification does not define a mapping or behavior for compatibility with this scenario. It will be considered in a future version of the specification.
 			</section>
-			This requires that user agents provide a different mapping for these types of input devices. Whenever a user agent is to dispatch a pointer event for a device that <a href=#mapping-for-devices-that-do-not-support-hover>does not support hover</a>, it MAY run the following steps:
+			This requires that user agents provide a different mapping for these types of input devices. Whenever a user agent is to dispatch a pointer event for a device that <a href=#mapping-for-devices-that-do-not-support-hover>does not support hover</a>, it SHOULD run the following steps:
 				<ol>
 					<li>If the <code>isPrimary</code> property for the pointer event to be dispatched is <code>false</code> then dispatch the pointer event and terminate these steps.</li>
 					<li>If the pointer event to be dispatched is <code>pointerover</code> and the <code>pointerdown</code> event has not yet been dispatched for this pointer, then fire a <code>mousemove</code> event (for compatibility with legacy mouse-specific code).</li>
+					<li>If the pointer event to be is dispatched is <code>pointerdown</code>, <code>pointerup</code> or <code>pointermove</code>, dispatch compatibility mouse transition events as described in <a>Tracking the effective position of the legacy mouse pointer</a>.</li>
 					<li>Dispatch the pointer event.</li>
 					<li>If the pointer event dispatched was <code>pointerdown</code> and the event was <a data-lt="canceled event">canceled</a>, then set the <i>PREVENT MOUSE EVENT</i> flag for this <code>pointerType</code>.</li>
-					<li>If the pointer event dispatched was: 
-						<ul>
-							<li><code>pointerover</code>, then fire a <code>mouseover</code> event.</li>
-							<li><code>pointerout</code>, then fire a <code>mouseout</code> event.</li>
-							<li><code>pointerenter</code>, then fire a <code>mouseenter</code> event.</li>
-							<li><code>pointerleave</code>, then fire a <code>mouseleave</code> event.</li>
-						</ul>
-					</li>					
 					<li>If the <i>PREVENT MOUSE EVENT</i> flag is <b>not</b> set for this <code>pointerType</code> and the pointer event dispatched was:
 						<ul>
 							<li><code>pointerdown</code>, then fire a <code>mousedown</code> event.</li>
 							<li><code>pointermove</code>, then fire a <code>mousemove</code> event.</li>
 							<li><code>pointerup</code>, then fire a <code>mouseup</code> event.</li>
-							<li><code>pointercancel</code>, then fire a <code>mouseup</code> event at the <code>window</code>.</b></li>
+							<li><code>pointercancel</code>, then fire a <code>mouseup</code> event at the <code>window</code>.</li>
 						</ul>
 					</li>
 					<li>If the pointer event dispatched was <code>pointerup</code> or <code>pointercancel</code>, clear the <i>PREVENT MOUSE EVENT</i> flag for this <code>pointerType</code>.</li>
