Intent to Implement and Ship: ongot/lostpointercaptures in GlobalEventHandlers

[Navid Zolghadr]

Contact emails
nzol...@chromium.org

Spec
https://w3c.github.io/pointerevents/#extensions-to-the-globaleventhandlers-interface

Summary
Previously in PointerEvents spec v1 (https://www.w3.org/TR/pointerevents/) ongotpointercapture and onlostpointercapture were attributes as part of the Element, driven by the idea that the target can only ever be an Element. Now we are moving them to GlobalEventHandlers to make them consistent with the other on'event' attributes as it is possible to listen to these events in their capturing dispatch phase. Note that this way of listening to the events through on'event' attributes are legacy and should not be mostly used. But this change makes sure they are all consistent.

Motivation

There was a web developer reported issue regarding the onpointerdown attribute. So for consistency in the spec ongot/lostpointercapture attributes have been added to the GlobalEventHandlers IDL.

Interoperability risk
Firefox: No public signals
Edge: Public support
Safari: No public signals
Web developers: No signals

Compatibility risk
The risk should be minimal as for the most part we are expanding the scope of definition of the attribute. All code using ongotpointercapture and onlostpointercapture today will continue to work after this change.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)? Yes

OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=674290

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/5702802084986880

Requesting approval to ship? Yes

[Rick Byers]

LGTM1

This is practically just a bug fix IMHO, but is technically a "new API" so thanks for going through the process!

[Dimitri Glazkov]

LGTM2

[Chris Harrelson]

LGTM3

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Boris Zbarsky]

On 12/19/16 8:49 AM, Navid Zolghadr wrote:
> Now we are moving
> them to GlobalEventHandlers to make them consistent with the other
> on'event' attributes as it is possible to listen to these events in
> their capturing dispatch phase.

Except you can't use on* attributes to add capturing listeners. So they
will be completely useless in practice, if the event doesn't bubble. I
_think_ these events don't bubble. It's a bit hard to tell because
https://w3c.github.io/pointerevents/#firing-events-using-the-pointerevent-interface
links to an old and less-clear version of the DOM spec, but if I assume
it should be linking to the current version then the event certainly
won't bubble the way it's being fired right now.

> Note that this way of listening to the
> events through on'event' attributes are legacy and should not be mostly
> used.

In this case it shouldn't be used at all, right? Because you will never
see the event.

Unless we're talking about scripts explicitly redispatching it on Window
or Document?

> There was a web developer reported issue

> <https://bugs.chromium.org/p/chromium/issues/detail?id=673162>regarding

> the onpointerdown attribute. So for consistency in the spec
> ongot/lostpointercapture attributes have been added to the
> GlobalEventHandlers IDL.

I don't see why fixing the onpointerdown attribute thing needed the
event to be added to GlobalEventHandlers. What needed to happen here
was to define that this is an "event handler IDL attribute"; what
interfaces the on* IDL thing appears on is totally orthogonal to that.

> Firefox: No public signals

Note that Firefox has this thing in GlobalEventHandlers at the moment,
but I'm pretty sure we have it behind a flag too, and not shipping yet.

-Boris

[Rick Byers]

On Mon, Dec 19, 2016 at 3:17 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 12/19/16 8:49 AM, Navid Zolghadr wrote:

Now we are moving
them to GlobalEventHandlers to make them consistent with the other
on'event' attributes as it is possible to listen to these events in
their capturing dispatch phase.

Except you can't use on* attributes to add capturing listeners.  So they will be completely useless in practice, if the event doesn't bubble.  I _think_ these events don't bubble.  It's a bit hard to tell because https://w3c.github.io/pointerevents/#firing-events-using-the-pointerevent-interface links to an old and less-clear version of the DOM spec, but if I assume it should be linking to the current version then the event certainly won't bubble the way it's being fired right now.

I agree we should be consistent and reference WHATWG-DOM everywhere instead of the old W3C copy.  Filed spec issue.

That said, gotpointercapture and lostpointercapture are listed as having bubbles=true and the firing algorithm says (in a not terribly precise fashion) to set those attributes.  So it's not obvious to me why you'd said they won't bubble according to the current firing algorithm.

And we've verified that listeners added with window.addEventListener do see the events today on Edge and Chrome.

[Boris Zbarsky]

On 12/19/16 12:47 PM, Rick Byers wrote:
> That said, gotpointercapture and lostpointercapture are listed

> <https://w3c.github.io/pointerevents/#pointer-event-types> as having

> bubbles=true and the firing algorithm

> <https://w3c.github.io/pointerevents/#firing-events-using-the-pointerevent-interface>

> says (in a not terribly precise fashion) to set those attributes.

Ah, I see. That part really needs to be tightened up to be clearer...
It looked to me like it wasn't setting "bubbles" anywhere, hence firing
a non-bubbling event.

If these are bubbling, putting this on GlobalEventHandlers makes perfect
sense.

-Boris