W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2015

Re: Capture semantics for a node that moves between documents

From: Rick Byers <rbyers@chromium.org>
Date: Wed, 6 May 2015 20:41:07 -0400
Message-ID: <CAFUtAY9PbjkOUemV=VLKvhE5EbzeXa+WAs-D-rJA9LiKduL+Pw@mail.gmail.com>
To: Scott González <scott.gonzalez@gmail.com>
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Ahh, I missed that - thanks.  So I suppose an app could address the use
case here by listening for lostpointercapture, detecting that the node is
now in a new document, and as a result re-requesting capture.  I worry a
little about accidental endless capture flip-flopping due to multiple
components fighting over attempting to regain capture.  But I agree the
spec covers this, we can table this unless specific usage issues come up in
practice.

Thanks!

Rick

On Tue, May 5, 2015 at 10:20 AM, Scott González <scott.gonzalez@gmail.com>
wrote:

> 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
>>
>>
>
Received on Thursday, 7 May 2015 00:41:55 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 16 May 2015 00:31:59 UTC