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

On Wed, Apr 8, 2015 at 5:12 AM, Olli Pettay <olli@pettay.fi> wrote:

> 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 :/
>

I've verified this page is similarly broken on Firefox for Android and a
recent (touch events enabled) build of IE for Windows Phone.  We've
submitted a bug report to Apple and will avoid adding a hack to blink to
work around this bug (unless we uncover a broader usage of this pattern).

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
>>
>
>