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

Seems like Webkit also should fix that bug if they did not it already
(latest build, etc. who knows).

2015-04-08 19:07 GMT+03:00 Rick Byers <rbyers@chromium.org>:

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


-- 
@nekrtemplar <https://twitter.com/nekrtemplar>