- From: <bugzilla@jessica.w3.org>
- Date: Wed, 05 Mar 2014 16:37:45 +0000
- To: public-pointer-events-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24923 Rick Byers <rbyers@chromium.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbyers@chromium.org --- Comment #5 from Rick Byers <rbyers@chromium.org> --- Interesting, I assumed we wouldn't repeat the hit test (and so use the same target as the pointer event). Even if the element isn't removed the difference is still observable - eg. what if you pointerdown on something while it's animating, and by the time the pointerdown handler finishes (and mousedown is dispatched) there's a new element under the cursor? If we do a new hit test then it might cause surprises (code seeing only pointer or mouse events when you'd normally see both). Scott, doesn't the scenario you describe also come up with mouse-only events when an element is removed while a mousemove is being dispatched to it? That mousemove will never bubble up to the document, but in most cases you'll get another mousemove shortly. Personally I think UAs should be dispatching a fake mousemove when the DOM element under the mouse cursor changes (we've got a bug for this in blink - I don't think we do it reliably today but I'm planning on getting it improved). Anyway, I don't think the compat mouse event issue with pointer events necessarily makes things any worse. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 5 March 2014 16:37:46 UTC