Re: [w3c/uievents] Click event is not fired when the node is removed and then added back (#141)

Since `click` is fired to the "nearest common inclusive ancestor" of `mousedown` and `mouseup` targets (see [here](https://w3c.github.io/uievents/#events-mouseevent-event-order)), we need to redefine this term in the spec if we want to fire a click in this case.

If the `mousedown` target element is removed from DOM, it's ancestry in that DOM becomes undefined.  Later on, if the same element is added back to the same DOM and it receives a `mouseup`, the "nearest common inclusive ancestor" of `mousedown` and `mouseup` remains undefined IMO.  From this perspective, current Chrome and Safari behavior of not firing a `click` seems logical.  I find it unreasonable to expect the removed element (or the DOM, or the event dispatcher) to somehow bring back the past ancestry information to find the "nearest common inclusive ancestor".

To highlight this point, [here](https://codepen.io/mustaqahmed/pen/YzVNZjg?editors=1000) is another repro where the "moved element" changes its parent.  Current Chrome and Safari behavior is in-line with [DOM mutation algorithm](https://dom.spec.whatwg.org/#mutation-algorithms) (see more details in [this Chrome bug comment](https://bugs.chromium.org/p/chromium/issues/detail?id=716694#c75)), and I can't explain the `click` in Firefox!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/141#issuecomment-880062298