Re: Capture semantics for a node that moves between documents

For capture specifically, I think the spec is already clear. Moving an
element between documents requires two steps: 1) removing the element from
one document; 2) adding the element to another document. Section 10.3.1
Implicit Release of Pointer Capture says that the element loses capture as
soon as it's removed from its owner document.

On Thu, Apr 30, 2015 at 3:43 PM, Rick Byers <rbyers@chromium.org> wrote:

> Should the spec say something about how capture behaves on a node that
> moves between document?
>
> I came across a bug I filed for a real-world issue I saw here with touch
> events (details below), and it's not clear to me if pointer events and the
> explicit capture API make this any better.
>
> Rick
>
> ---------- Forwarded message ----------
> From: Rick Byers <rbyers@chromium.org>
> Date: Wed, Jul 16, 2014 at 10:55 AM
> Subject: Touch semantics when touched node changes documents (eg. polymer
> templates)
> To: "public-touchevents@w3.org" <public-touchevents@w3.org>
> Cc: polymer-dev <polymer-dev@googlegroups.com>, input-dev <
> input-dev@chromium.org>
>
>
> Hi,
> We've talked before about some of the implications of the implicit capture
> targeting model used by touch events.  Eg. that removing a node while
> touching it has surprising (but workable) behavior
> <https://plus.sandbox.google.com/+RickByers/posts/GHwpqnAFATf> [1].  And
> we've also talked about how multiple active touches in separate documents
> <http://www.w3.org/TR/touch-events/#touchevent-implementer-s-note> [2]
> should behave.
>
> But I've never heard any discussion about what browsers should do if a
> node moves documents while the target of a touch.  Here's a test page
> <http://jsbin.com/hupuci/1/edit> [3] that shows Safari and (prior to a
> crash I accidentally introduced <http://crbug.com/393822> [4]) Chrome
> appears to just stop sending any events in such a situation (not visible to
> the target node, original document, or new document).
>
> This seems problematic since the code handling the touch events may be
> logically separate (in another component, even owned by a different
> organization) than one that may be manipulating the DOM.  For example,
> imagine some infinite news feed (facebook etc.) with JavaScript-driven
> touch scrolling.  DOM elements may come and go (possibly to/from transient
> documents for staging purposes or nested iframes for isolation reasons)
> based on network activity disconnected from scrolling.  It shouldn't be
> necessary (even if it's desirable for performance reasons) to
> co-ordinate/suppress the DOM manipulation code with the touch handling code.
>
> I'm surprised I've never heard anyone complain about this before.
> Presumably it's one of those rare "touch doesn't work right but I don't
> understand why" cases.  Polymer's implementation of <template> elements
> <https://github.com/Polymer/TemplateBinding/blob/3168309eb131921f08e3a74e9d7197c903762bda/src/TemplateBinding.js#L1085>
> (the scenario I saw this hit in) could make this more common.  I've filed a
> bug <http://crbug.com/394339> to track addressing this in blink somehow.
>
> What do you think.  Do you agree this is something that should be
> addressed to improve rationality?  I've got a couple possible ideas, but
> I'd like to here from others.
>
> Thanks,
>    Rick
>
> [1] https://plus.sandbox.google.com/+RickByers/posts/GHwpqnAFATf
> [2] http://www.w3.org/TR/touch-events/#touchevent-implementer-s-note
> [3] http://jsbin.com/hupuci/1/edit
> [4] http://crbug.com/393822
> [5]
> https://github.com/Polymer/TemplateBinding/blob/3168309eb131921f08e3a74e9d7197c903762bda/src/TemplateBinding.js#L1085
> [6] http://crbug.com/394339
>
>