W3C home > Mailing lists > Public > public-webevents@w3.org > April to June 2014

Re: Touch events on removed element

From: Rick Byers <rbyers@chromium.org>
Date: Wed, 9 Apr 2014 20:29:54 -0400
Message-ID: <CAFUtAY-yXMBBa0PjpoEtKpnmwrUrvJE+D1kmwvm-w3M_mDfYKw@mail.gmail.com>
To: Ben Alpert <ben@benalpert.com>, "public-touchevents@w3.org" <public-touchevents@w3.org>
Cc: "public-webevents@w3.org" <public-webevents@w3.org>
Hi Ben,
The webevents working group is closed - there's no more active work on the
TouchEvent spec (see http://www.w3.org/2010/webevents/).  However we have a
new touch events community group to discuss issues like this (although
there's currently no plan to produce/update any specs).

I agree it would be nice if this was explicitly defined by the spec.  At
least it is kind of implicit in this sentence (in that it doesn't list an
exception for removal from the DOM):

 The target of this [touchmove] event must be the same Element on which the
touch point started when it was first placed on the surface, even if the
touch point has since moved outside the interactive area of the target
element.

Note that removing an element which is the target of an active touch can be
confusing for any event handlers on it's ancestor nodes (they may see a
touchstart without any corresponding touchend/touchcancel).  I discuss this
in my Google I/O talk here:
https://developers.google.com/events/io/sessions/361772634.

>From an implementation perspective, I can only speak authoritatively for
chrome: you should definitely be able to rely on this property.  We
explicitly keep elements alive which are the target of active touches.

However, we don't make the element a GC root, which means that if the
element isn't otherwise reachable, and it has the only references to some
other JS objects, those objects will appear unreachable to the GC and may
be collected (which you could observe when receiving a future touch event).
 I've always found this slightly surprising, but I figure it's pretty
unlikely to be an issue in practice and I've never heard any complaints so
I haven't bothered trying to address it.  Could this potentially be a
problem in your scenarios?

Rick


On Fri, Apr 4, 2014 at 7:26 PM, Ben Alpert <ben@benalpert.com> wrote:

> Hi all,
>
> (Hope this is the right list, please redirect me if not.)
>
> The touch events spec doesn't seem to be completely clear on what happens
> when a dragging interaction happens on an element that gets removed. With
> this code....
>
> <div id="monkey"></div>
>
> monkey.addEventListener("touchstart", function(e) {
>   if (e.target.parentNode) {
>     e.target.parentNode.removeChild(e.target);
>   }
> });
> monkey.addEventListener("touchmove", function(e) {
>   alert('touchmove on removed element');
> });
>
> (Live demo: http://jsbin.com/gocuhifa/1)
>
> ...is the touchmove handler guaranteed to be called even though the
> element is removed? It's not obvious from the spec that (a) removed
> elements are even capable of receiving events and (b) that the browser
> shouldn't GC the removed element and its handlers. Receiving this event is
> useful for certain draggable interactions (such as a sortable where the
> currently-dragging element is replaced with a placeholder element).
>
> Thankfully, it seems that in latest Chrome, Firefox, and iOS Safari the
> alert is fired. I'd be grateful if someone could clarify this in the spec
> or point me to where I blindly missed it. :)
>
> Thanks,
> Ben
>
Received on Thursday, 10 April 2014 00:30:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:09:35 UTC