This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#list-of-pointer-events says those events are asynchronous and so does https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-gotpointercapture-event and https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-lostpointercapture-event But the algorithm in https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#pointer-capture doesn't talk about tasks or async dispatching. It just says "Fire a gotpointercapture event at the Element on which this method was invoked." and "Fire a lostpointercapture event at the Element on which this method was invoked." The algorithm should probably say something like "...queue a task to fire a pointer event named 'got/lostpointercapture on element"
Actually, I don't understand what the spec tries to say "A user agent MUST queue a task to fire a pointer event named lostpointercapture after pointer capture is released for a pointer. This event MUST be fired prior to any subsequent events for the pointer after capture was released." So queue a task to fire event, but that firing must happen before something else. That makes no sense. We can't prioritize event dispatching task in the task queue to happen before something else.
Or should we dispatch got/lost async, but if we're about to get some new event for that particular pointer, then sync right before dispatching that new event?
I'm checking out implementation. But I think it's actually as Olli describes in Comment 2. The main thing I think we're trying to avoid here is overflowing the stack (calling setPointerCapture in a gotpointercapture listener repeatedly).
What should happen in case some pointer event listener does first releasePointerCapture(X) and then immediately setPointerCapture(X)? What should be the order of the various events and when should they happen, sync or async. Do we actually just need synchronous event dispatching here.
It's not truly "async" in the "queue a task" sense. The way IE does this is to set a "pending capture node" when setPointerCapture() is called. When it comes time to fire the next pointer event, we check to see if the pointer has a pending capture node. If it does, then we fire the gotpointercapture event prior to firing the next pointer event. We could make the spec capture this behavior more succinctly with a relatively simple change: 1. Remove step 4 from sections 10.1 and 10.2 2. Change step 3 of 10.1 and 10.2 to set and clear the 'pending pointer capture' node for the pointer, respectively 3. In section 5.2.1, add a step such that when you are to fire a pointer event, you first: "1. If the 'pointer capture target override' for this pointer is set and is not equal to the 'pending pointer capture' node, then fire a pointer event named lostpointercapture at the 'pointer capture target override' node. 2. If the 'pending pointer capture' node for this pointer is set and is not equal to the 'pointer capture target override', then fire a pointer event named gotpointercapture at the 'pending pointer capture' node. 3. Set the 'pointer capture target override' to the 'pending pointer capture' node, if set. Otherwise, clear the 'pointer capture target override'." 4. Remove "queue a task to" from sections 5.2.11 and 5.2.12 This would also effectively resolve Bug 25147, I believe: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25147
Fixed as described (modulo some tweaks) above: https://dvcs.w3.org/hg/pointerevents/rev/06a63f400a2a