Re: hasOwnProperty('touches') for differentiating a TouchEvent from a MouseEvent

On 04/08/2015 05:57 AM, Rick Byers wrote:
> [Trying again to get the pain-text code snippet formatted correctly in the archives (sorry for the spam)]
>
> Here's a funny pattern we just noticed <https://code.google.com/p/chromium/issues/detail?id=474436#c12> for code attempting to handle both touch and
> mouse events with the same code:
>
> getPointerPosition = function(j) {
>    if (j.hasOwnProperty("touches")) {
>      return {x: j.changedTouches[0].pageX,y: j.changedTouches[0].pageY} }
>    else {
>      return {x: j.pageX,y: j.pageY} } }
>   ...
> g._onPointerDown = function(k) {
>    if (!k.hasOwnProperty("touches")) {
>      k.preventDefault()
>    }
>    this.mouse = h.getPointerPosition(k);
>    this.prevMouse = {x: this.mouse.x,y: this.mouse.y};
>    this._isDragging = true;
>    this._onWillBeginTracking();
>    document.addEventListener("mousemove", this._boundFunctions.onPointerDrag, false);
>    document.addEventListener("touchmove", this._boundFunctions.onPointerDrag, false);
>    document.addEventListener("mouseup", this._boundFunctions.onPointerUp, false);
>    document.addEventListener("touchend", this._boundFunctions.onPointerUp, false);
>    document.addEventListener("touchcancel", this._boundFunctions.onPointerUp, false)
> };
>
> This used to work to identify TouchEvents in Chrome (and Safari) due a longstanding bug
> <https://code.google.com/p/chromium/issues/detail?id=43394>where DOM attributes were incorrectly exposed on the instance
> <https://docs.google.com/document/d/1yeHTCHhulVIlrKyx9_gCguAhLfcefVOa9uxxfW2LVG0/edit>, instead of on the prototype chain (as required by WebIDL
> <http://heycam.github.io/webidl/#es-operations>). The code should really be using '"touches" in j' instead of using hasOwnProperty here.
>
> Ironically, the site that has this code attempting (but failing) to handle mouse and touch events with the same event handlers:
> http://www.apple.com/watch/gallery/
>
> We're trying to ship our fix for the DOM attributes bug now (but may resort to a temporary compat hack to avoid breaking such sites). I assume such
> pages are be broken on IE and Firefox (which have correctly implementing DOM attributes on the prototype chain for some time), right?

Pages tend to have separate code paths for different browsers :/

The only, IIRC,  event handling related hack we had to add when implementing webidl stuff was,
onmouseenter/leave[1] requiring [LenientThis], and that had to be added to the spec too.

And more like a feature is then [Unforgeable] in Event's isTrusted[2].


  Have folks seen
> other sites with this problem (searching github I see this pattern in a few places)?

Haven't heard of that issue before.


(So great to see Blink getting better webidl implementation!)

-Olli

[1] https://html.spec.whatwg.org/multipage/webappapis.html#globaleventhandlers
[2] https://dom.spec.whatwg.org/#interface-event


>
> Rick

Received on Wednesday, 8 April 2015 09:13:22 UTC