Intent to Ship: Pointer Events

[Mustaq Ahmed]

Contact emails

rby...@chromium.org, mus...@chromium.org

Target

Approval requested for M55.

Spec

https://w3c.github.io/pointerevents/

Summary

The Pointer Events API is a low-level input API for mouse, touch and stylus first introduced by Microsoft and then standardized in the W3C.  The API extends the MouseEvent model to provide an input-modality-agnostic event handling mechanism, covering all uses of Mouse and Touch events.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ODWmcKNQl0I

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

Yes.

Demo link

https://patrickhlauke.github.io/touch/

Debuggability

The PointerEvent API is already supported in devtools.  In particular, console commands getEventListeners(), monitorEvents() and unmonitorEvents() already work for PointerEvents, and the debugging sidebar pane allows setting event listener breakpoints for any/all types of PointerEvents.

Interoperability and Compatibility Risk

IE/Edge: Public support (shipping since IE10)

Firefox: Public support (implementation in progress, available behind a flag)

Safari: Publicly opposed  

Web developers: Mostly positive public support, including jQuery and Dojo.

Interoperability and compatibility risk is low because of following reasons.

1. While implementing, we have been actively engaged with the Pointer Events Working Group, particularly with Microsoft, to address all major technical issues.  For all these issues, either we engaged other vendors to update their implementation & fix the spec accordingly, or changed our implementation to match the spec.  At this point in time, we have only minor/futuristic spec issues to resolve.  This close collaboration with the community helped us come to a consensus on a model for pointer, touch and mouse events that is highly interoperable between Edge, Chrome and Firefox, while remaining compatible with Safari’s implementation of touch and mouse events.  Two major implementation issues have been resolved via breaking spec changes:

1. Implicit Capture for touch is enabled by default, and

2. Boundary Events are not sent during capturing.

2. Although Pointer Events has pretty broad support for many years already, the lack of browser support (other than Edge) raised the bar high for early adaptation.  Our usage stats suggests that ~1% of the pageviews use the API, and most of them use the API in an elementary (i.e. MouseEvent-like) manner.  Our extensive manual compat testing both before & during the Implementation Hackathon with Microsoft, Mozilla & jQuery found no behavioral difference with Edge.

3. Chrome Canary and Dev channels have PointerEvents enabled (100%) via finch since M54.  Chrome Beta and Chrome Stable will also have it enabled for respectively 50% and 1% of our users as M54 rolls out.  We have found a few sites with bugs that are triggered when both touch and pointer events are supported, but these sites are similarly broken on Windows 10 Mobile.  Many sites of this form that were broken in Edge are “fixed” by the removal of the ‘pointerEnabled’ API which was the original recommended way to feature detect for PointerEvents.  We have not yet encountered any site that is broken as a result of the changes to the specification relative to what Edge has already shipped.  If we encounter substantial breakage we’ll circle back with this thread before 55 hits stable.  

OWP launch tracking bug

http://crbug.com/196799

Entry on the feature dashboard

https://www.chromestatus.com/features/4504699138998272

[Dimitri Glazkov]

LGTM1

[Philip Jägenstedt]

The work on interop and compat here is exemplary, thank you! How comprehensive is https://github.com/w3c/web-platform-tests/tree/master/pointerevents and do you know which tests are failing in which engines?

I see that the PointerEvent interface has a tangentialPressure member in the spec but not in Blink, is this a recent addition to the spec?

It is unusual to have another vendor publicly opposed. That was in 2012, has there been no public comment from WebKit developers since?

[Navid Zolghadr]

Regarding the web platform tests, we have them run automatically on our bots using their automation scripts from here and they are passing. There are a few being skipped like the ones that need touch on Mac (as it doesn't support it) or the new changes that Chrome implemented and test suite is not yet updated as the changes recently went to the main branch.  But we do have some Blink layout tests for the implicit capture and boundary events.

--
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+...@chromium.org.

[Dave Tapuska]

tangentialPressure was added to the spec here:

https://github.com/w3c/pointerevents/commit/efe7d4f6b891a2a3f53112ca9d7b262462465c2d

I've logged crbug.com/649376 to ensure we have the definition in the IDLs.

dave.

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

[Chris Harrelson]

LGTM2

[Rick Byers]

On Thu, Sep 22, 2016 at 5:08 PM, 'Dave Tapuska' via blink-dev <blin...@chromium.org> wrote:

tangentialPressure was added to the spec here:

https://github.com/w3c/pointerevents/commit/efe7d4f6b891a2a3f53112ca9d7b262462465c2d

I've logged crbug.com/649376 to ensure we have the definition in the IDLs.

dave.

On Thu, Sep 22, 2016 at 11:58 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

The work on interop and compat here is exemplary, thank you! How comprehensive is https://github.com/w3c/web-platform-tests/tree/master/pointerevents and do you know which tests are failing in which engines?

I see that the PointerEvent interface has a tangentialPressure member in the spec but not in Blink, is this a recent addition to the spec?

It is unusual to have another vendor publicly opposed. That was in 2012, has there been no public comment from WebKit developers since?

IIRC there have been a number of public (or semi-public) comments since then, but all of the form "we can't comment on pointer events" <grin>.

Suffice it to say, I see no reason to believe that Apple will ever ship pointer events - but it's impossible to predict what could happen if there was sufficient developer demand.  I.e. we're in the same state there that we were when we made the decision to restart our investments in PE.  Personally I found this to be a tough trade-off (I of course care a LOT about Safari interop on mobile), but ultimately people succeeded in convincing me that it was important to have SOME healthy standards forum for evolving touch input on the web, and 3 out of 4 browsers participating in pointer events was better than roughly 1 (just us) publicly and actively participating in the touch events specification.

[Chris Harrelson]

My LGTM still stands, but a question: what's the status of avoiding hit testing on pointer move? I assume our implementation avoids it; will Edge follow suit? Any interesting performance examples to share showing

improved performance over touch APIs?

Chris

[Jochen Eisinger]

lgtm3 fwiw

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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+...@chromium.org.

[jacob...@microsoft.com]

On Thu, Sep 22, 2016 at 11:58 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

The work on interop and compat here is exemplary, thank you! How comprehensive is https://github.com/w3c/web-platform-tests/tree/master/pointerevents and do you know which tests are failing in which engines?

I see that the PointerEvent interface has a tangentialPressure member in the spec but not in Blink, is this a recent addition to the spec?

It is unusual to have another vendor publicly opposed. That was in 2012, has there been no public comment from WebKit developers since?

IIRC there have been a number of public (or semi-public) comments since then, but all of the form "we can't comment on pointer events" <grin>.

Suffice it to say, I see no reason to believe that Apple will ever ship pointer events - but it's impossible to predict what could happen if there was sufficient developer demand.  I.e. we're in the same state there that we were when we made the decision to restart our investments in PE.  Personally I found this to be a tough trade-off (I of course care a LOT about Safari interop on mobile), but ultimately people succeeded in convincing me that it was important to have SOME healthy standards forum for evolving touch input on the web, and 3 out of 4 browsers participating in pointer events was better than roughly 1 (just us) publicly and actively participating in the touch events specification.

+1 - I'm excited to see us finally converge on this.  While it is truly unusual to have a vendor opposed, it's doubly unusual that we can't really resolve that opposition given Apple doesn't participate in touch standards working groups of any kind.  With that in mind, I think the best thing we can do for the web developer ecosystem is to provide an interoperable API across all of the other browsers (we're on track for this!) and maintain a high quality polyfill for interoperable support on iOS (PEP.js). Web developers largely seem to agree and desire this approach as well. In time, it's possible that creates interop pressure on Apple to implement -- but I'm not anticipating that any time soon.

 

On Thu, Sep 22, 2016 at 5:39 PM Mustaq Ahmed <mus...@chromium.org> wrote:

[snip]

Interoperability and Compatibility Risk

IE/Edge: Public support (shipping since IE10)

Firefox: Public support (implementation in progress, available behind a flag)

Safari: Publicly opposed  

Web developers: Mostly positive public support, including jQuery and Dojo.

Interoperability and compatibility risk is low because of following reasons.

1. While implementing, we have been actively engaged with the Pointer Events Working Group, particularly with Microsoft, to address all major technical issues.  For all these issues, either we engaged other vendors to update their implementation & fix the spec accordingly, or changed our implementation to match the spec.  At this point in time, we have only minor/futuristic spec issues to resolve.  This close collaboration with the community helped us come to a consensus on a model for pointer, touch and mouse events that is highly interoperable between Edge, Chrome and Firefox, while remaining compatible with Safari’s implementation of touch and mouse events.  Two major implementation issues have been resolved via breaking spec changes:

1. Implicit Capture for touch is enabled by default, and

2. Boundary Events are not sent during capturing.

2. Although Pointer Events has pretty broad support for many years already, the lack of browser support (other than Edge) raised the bar high for early adaptation.  Our usage stats suggests that ~1% of the pageviews use the API, and most of them use the API in an elementary (i.e. MouseEvent-like) manner.  Our extensive manual compat testing both before & during the Implementation Hackathon with Microsoft, Mozilla & jQuery found no behavioral difference with Edge.

3. Chrome Canary and Dev channels have PointerEvents enabled (100%) via finch since M54.  Chrome Beta and Chrome Stable will also have it enabled for respectively 50% and 1% of our users as M54 rolls out.  We have found a few sites with bugs that are triggered when both touch and pointer events are supported, but these sites are similarly broken on Windows 10 Mobile.  Many sites of this form that were broken in Edge are “fixed” by the removal of the ‘pointerEnabled’ API which was the original recommended way to feature detect for PointerEvents.  We have not yet encountered any site that is broken as a result of the changes to the specification relative to what Edge has already shipped.  If we encounter substantial breakage we’ll circle back with this thread before 55 hits stable.  

I added Ted who's driving the implementation these days in Edge. I believe they're working on all the minor differences identified here, in particular #1. I think he has a build he is demo'ing at TPAC that demonstrates interoperability with these changes implemented. We'll of course monitor compat impact as we roll this out in preview builds. But I don't personally anticipate any major issues here. 

 

On Thursday, September 22, 2016 at 10:19:09 AM UTC-7, Chris Harrelson wrote:

My LGTM still stands, but a question: what's the status of avoiding hit testing on pointer move? I assume our implementation avoids it; will Edge follow suit? Any interesting performance examples to share showing

improved performance over touch APIs?

Yes, we're making the changes detailed in #1 above to align on avoiding hit testing on pointer move in Edge. Ted can comment further on our progress there. I expect we'll see preview builds with this in the coming weeks/months at least under a flag.

[Alex Russell]

Super excited about this. Nice work, all.

lgtm3 fwiw

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

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

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

[Mustaq Ahmed]

On Thu, Sep 22, 2016 at 1:24 PM, Alex Russell <sligh...@google.com> wrote:

Super excited about this. Nice work, all.

On Thu, Sep 22, 2016 at 6:23 PM, Jochen Eisinger <joc...@chromium.org> wrote:

lgtm3 fwiw

On Thu, Sep 22, 2016 at 6:19 PM Chris Harrelson <chri...@chromium.org> wrote:

My LGTM still stands, but a question: what's the status of avoiding hit testing on pointer move? I assume our implementation avoids it; will Edge follow suit? Any interesting performance examples to share showing

improved performance over touch APIs?

Our implementation avoids pointermove histests for all captured pointers---touch is captured implicitly hence no pointermove hittest by default. The pointermove events for uncaptured pointers do go through hittests: e.g. default (i.e. uncaptured) mouse moves, and the touch moves that got released through releasepointerCapture().

Edge agreed to avoid hittesting for implicit capture but proposed hittesting for explicit capture only. The motivation is the boundary (pointerenter/leave/over/out) events in this case, being discussed here.

[Philip Jägenstedt]

On Thu, Sep 22, 2016 at 6:45 PM Rick Byers <rby...@chromium.org> wrote:

On Thu, Sep 22, 2016 at 5:08 PM, 'Dave Tapuska' via blink-dev <blin...@chromium.org> wrote:

tangentialPressure was added to the spec here:

https://github.com/w3c/pointerevents/commit/efe7d4f6b891a2a3f53112ca9d7b262462465c2d

I've logged crbug.com/649376 to ensure we have the definition in the IDLs.

dave.

On Thu, Sep 22, 2016 at 11:58 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

The work on interop and compat here is exemplary, thank you! How comprehensive is https://github.com/w3c/web-platform-tests/tree/master/pointerevents and do you know which tests are failing in which engines?

I see that the PointerEvent interface has a tangentialPressure member in the spec but not in Blink, is this a recent addition to the spec?

It is unusual to have another vendor publicly opposed. That was in 2012, has there been no public comment from WebKit developers since?

IIRC there have been a number of public (or semi-public) comments since then, but all of the form "we can't comment on pointer events" <grin>.

Suffice it to say, I see no reason to believe that Apple will ever ship pointer events - but it's impossible to predict what could happen if there was sufficient developer demand.  I.e. we're in the same state there that we were when we made the decision to restart our investments in PE.  Personally I found this to be a tough trade-off (I of course care a LOT about Safari interop on mobile), but ultimately people succeeded in convincing me that it was important to have SOME healthy standards forum for evolving touch input on the web, and 3 out of 4 browsers participating in pointer events was better than roughly 1 (just us) publicly and actively participating in the touch events specification.

I agree with this trade-off, just wanted to have it explicit here, thanks Rick.

LGTM4

[Rick Byers]

[Re-sending Jacob's message, since most GMail users won't see it due to an SPF failure - apparently SPF domains can't sent from the google groups web interface]

---------- Forwarded message ----------
From: <jacob...@microsoft.com>
Date: Thu, Sep 22, 2016 at 6:24 PM
Subject: Re: [blink-dev] Intent to Ship: Pointer Events
To: blink-dev <blin...@chromium.org>
Cc: rby...@chromium.org, dtap...@google.com, foo...@chromium.org, mus...@chromium.org, chri...@chromium.org, Ted.Din...@microsoft.com

On Thu, Sep 22, 2016 at 11:58 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

The work on interop and compat here is exemplary, thank you! How comprehensive is https://github.com/w3c/web-platform-tests/tree/master/pointerevents and do you know which tests are failing in which engines?

I see that the PointerEvent interface has a tangentialPressure member in the spec but not in Blink, is this a recent addition to the spec?

It is unusual to have another vendor publicly opposed. That was in 2012, has there been no public comment from WebKit developers since?

IIRC there have been a number of public (or semi-public) comments since then, but all of the form "we can't comment on pointer events" <grin>.

Suffice it to say, I see no reason to believe that Apple will ever ship pointer events - but it's impossible to predict what could happen if there was sufficient developer demand.  I.e. we're in the same state there that we were when we made the decision to restart our investments in PE.  Personally I found this to be a tough trade-off (I of course care a LOT about Safari interop on mobile), but ultimately people succeeded in convincing me that it was important to have SOME healthy standards forum for evolving touch input on the web, and 3 out of 4 browsers participating in pointer events was better than roughly 1 (just us) publicly and actively participating in the touch events specification.

+1 - I'm excited to see us finally converge on this.  While it is truly unusual to have a vendor opposed, it's doubly unusual that we can't really resolve that opposition given Apple doesn't participate in touch standards working groups of any kind.  With that in mind, I think the best thing we can do for the web developer ecosystem is to provide an interoperable API across all of the other browsers (we're on track for this!) and maintain a high quality polyfill for interoperable support on iOS (PEP.js). Web developers largely seem to agree and desire this approach as well. In time, it's possible that creates interop pressure on Apple to implement -- but I'm not anticipating that any time soon.

 

On Thu, Sep 22, 2016 at 5:39 PM Mustaq Ahmed <mus...@chromium.org> wrote:

[snip]

Interoperability and Compatibility Risk

IE/Edge: Public support (shipping since IE10)

Firefox: Public support (implementation in progress, available behind a flag)

Safari: Publicly opposed  

Web developers: Mostly positive public support, including jQuery and Dojo.

Interoperability and compatibility risk is low because of following reasons.

1. While implementing, we have been actively engaged with the Pointer Events Working Group, particularly with Microsoft, to address all major technical issues.  For all these issues, either we engaged other vendors to update their implementation & fix the spec accordingly, or changed our implementation to match the spec.  At this point in time, we have only minor/futuristic spec issues to resolve.  This close collaboration with the community helped us come to a consensus on a model for pointer, touch and mouse events that is highly interoperable between Edge, Chrome and Firefox, while remaining compatible with Safari’s implementation of touch and mouse events.  Two major implementation issues have been resolved via breaking spec changes:

1. Implicit Capture for touch is enabled by default, and

2. Boundary Events are not sent during capturing.

2. Although Pointer Events has pretty broad support for many years already, the lack of browser support (other than Edge) raised the bar high for early adaptation.  Our usage stats suggests that ~1% of the pageviews use the API, and most of them use the API in an elementary (i.e. MouseEvent-like) manner.  Our extensive manual compat testing both before & during the Implementation Hackathon with Microsoft, Mozilla & jQuery found no behavioral difference with Edge.

3. Chrome Canary and Dev channels have PointerEvents enabled (100%) via finch since M54.  Chrome Beta and Chrome Stable will also have it enabled for respectively 50% and 1% of our users as M54 rolls out.  We have found a few sites with bugs that are triggered when both touch and pointer events are supported, but these sites are similarly broken on Windows 10 Mobile.  Many sites of this form that were broken in Edge are “fixed” by the removal of the ‘pointerEnabled’ API which was the original recommended way to feature detect for PointerEvents.  We have not yet encountered any site that is broken as a result of the changes to the specification relative to what Edge has already shipped.  If we encounter substantial breakage we’ll circle back with this thread before 55 hits stable.  

I added Ted who's driving the implementation these days in Edge. I believe they're working on all the minor differences identified here, in particular #1. I think he has a build he is demo'ing at TPAC that demonstrates interoperability with these changes implemented. We'll of course monitor compat impact as we roll this out in preview builds. But I don't personally anticipate any major issues here. 

 

On Thursday, September 22, 2016 at 10:19:09 AM UTC-7, Chris Harrelson wrote:

My LGTM still stands, but a question: what's the status of avoiding hit testing on pointer move? I assume our implementation avoids it; will Edge follow suit? Any interesting performance examples to share showing

improved performance over touch APIs?

[Joe Medley]

Rick,

Just to clarify, Pointer Events were already in M54 and this is just the paperwork catching up to reality? Is that correct?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Mustaq Ahmed]

Hi Joe:

We are not shipping Pointer Events until M55 Stable. Before that, only 1% of M54 Stable users will have it enabled by default for bug fixing, compat testing etc (in addition to 50% of M54 Beta and 100% of Canary users).

Mustaq

[PhistucK]

Firefox mentioned enabling pointer events by default on Firefox Nightly in August, 2015 (more than a year ago) and has not enabled it by default in stable (is it even enabled by default in Nightly? This open bug suggests that it is not).

The fact that the current browser support (Microsoft browsers only, basically) has not changed at all since the intent to implement is actually extremely disconcerting to me.

Does anyone know why Firefox has not shipped pointer events already? Is the plan to ship them after Chrome ships?

Adding Boris, in case he is in the loop (sorry for appointing you as the official representative for everything from Mozilla :().

☆PhistucK

[Kartikaya Gupta]

On Fri, Sep 23, 2016 at 4:28 PM, PhistucK <phis...@gmail.com> wrote:
> Firefox mentioned enabling pointer events by default on Firefox Nightly in
> August, 2015 (more than a year ago) and has not enabled it by default in
> stable (is it even enabled by default in Nightly? This open bug suggests
> that it is not).
> The fact that the current browser support (Microsoft browsers only,
> basically) has not changed at all since the intent to implement is actually
> extremely disconcerting to me.
>
> Does anyone know why Firefox has not shipped pointer events already? Is the
> plan to ship them after Chrome ships?

The initial implementation (the one you cite from last year) was being
done by a contractor and the quality of the implementation was not
really good enough to ship. The contractor's contract expired and the
code sat in the tree, disabled, and gradually rotted, until a few
months ago when it was picked up again. It is being worked on actively
now.

Cheers,
kats

[PhistucK]

Thank you for the update! Do you plan to ship this in the coming months?

☆PhistucK

[Kartikaya Gupta]

Yes, although I don't know exactly when.

Cheers,
kats

[Ted Dinklocker]

Ted from Microsoft Edge here.

 

As Rick mentioned, our intention right now is that we will ship with implicit capture for touch ON by default, which means no hit testing on pointer move and not firing boundary events. There will be a flag to revert this behavior, although that part has not yet been implemented. There is a current bug on Edge that we are tracking regarding an event ordering difference between Chrome and Edge – it is unclear right now whether it would be an interoperability issue or not.

 

At this point, the Edge implementation will continue to hit test and send boundary events when a developer explicitly calls SetPointerCapture. We are involved with the discussion that Rick mentioned to come to consensus on the best behavior for explicit capture.

 

Ted

1.     While implementing, we have been actively engaged with the Pointer Events Working Group, particularly with Microsoft, to address all major technical issues.  For all these issues, either we engaged other vendors to update their implementation & fix the spec accordingly, or changed our implementation to match the spec.  At this point in time, we have only minor/futuristic spec issues to resolve.  This close collaboration with the community helped us come to a consensus on a model for pointer, touch and mouse events that is highly interoperable between Edge, Chrome and Firefox, while remaining compatible with Safari’s implementation of touch and mouse events.  Two major implementation issues have been resolved via breaking spec changes:

a.     Implicit Capture for touch is enabled by default, and

b.     Boundary Events are not sent during capturing.

2.     Although Pointer Events has pretty broad support for many years already, the lack of browser support (other than Edge) raised the bar high for early adaptation.  Our usage stats suggests that ~1% of the pageviews use the API, and most of them use the API in an elementary (i.e. MouseEvent-like) manner.  Our extensive manual compat testing both before & during the Implementation Hackathon with Microsoft, Mozilla & jQuery found no behavioral difference with Edge.

3.     Chrome Canary and Dev channels have PointerEvents enabled (100%) via finch since M54.  Chrome Beta and Chrome Stable will also have it enabled for respectively 50% and 1% of our users as M54 rolls out.  We have found a few sites with bugs that are triggered when both touch and pointer events are supported, but these sites are similarly broken on Windows 10 Mobile.  Many sites of this form that were broken in Edge are “fixed” by the removal of the ‘pointerEnabled’ API which was the original recommended way to feature detect for PointerEvents.  We have not yet encountered any site that is broken as a result of the changes to the specification relative to what Edge has already shipped.  If we encounter substantial breakage we’ll circle back with this thread before 55 hits stable.  

 

I added Ted who's driving the implementation these days in Edge. I believe they're working on all the minor differences identified here, in particular #1. I think he has a build he is demo'ing at TPAC that demonstrates interoperability with these changes implemented. We'll of course monitor compat impact as we roll this out in preview builds. But I don't personally anticipate any major issues here. 

 

On Thursday, September 22, 2016 at 10:19:09 AM UTC-7, Chris Harrelson wrote:

My LGTM still stands, but a question: what's the status of avoiding hit testing on pointer move? I assume our implementation avoids it; will Edge follow suit? Any interesting performance examples to share showing

improved performance over touch APIs?

 

Yes, we're making the changes detailed in #1 above to align on avoiding hit testing on pointer move in Edge. Ted can comment further on our progress there. I expect we'll see preview builds with this in the coming weeks/months at least under a flag.

 

--
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+...@chromium.org.

 

 

[ufab...@googlemail.com]

Hello there,

This is Fabian from Drupal, where we recently enabled pointer events via a jQuery binding.

We received bug reports (probably those 1% that have it enabled in stable) of drag and drop being broken in our latest stable release, but only on Chrome.

The strange thing is:

   It works in Firefox with the option enabled (and apparently IE 10).

The code to reproduce is:

  jQuery(document).bind('pointermove', function(ev) { console.log(ev.clientX); });

which fails with undefined property.

While obviously:

  jQuery(document).bind('pointermove', function(ev) { console.log(ev.originalEvent.clientX); });

works.

However jQuery (pretty old version though) correctly copies the event.clientX property in Firefox, but fails in Chrome. Maybe it cannot detect the mouse event inheritance somehow?

Not sure this is really a bug though, so just reporting the finding here.

Thanks,

Fabian

[PhistucK]

Please, use crbug.com even for potentional bugs. The intent thread is not the right place anyway.

Thank you!

☆PhistucK

--

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.

[PhistucK]

I updated Chrome to the latest stable (Chrome 55) on Windows 7 and pointer events seems to be disabled (no PointerEvent on window, no onpointermove on document.body), despite the beta blog post announcement.

The code suggests that it is enabled -

https://chromium.googlesource.com/chromium/src/+/55.0.2883.75/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in#173

chrome://flags/#enable-pointer-events is set to Default.

Was it postponed to Chrome 56? Or is it on a high-percentage field trial?

☆PhistucK

[Rick Byers]

Yikes, it is supposed to be on in 55 AFAIK.  Mustaq?  Finch config issue perhaps?

It appears on by default on Chrome 55 Android (still in beta).

[cor...@gmail.com]

I also tried the latest Chrome 55 on Windows 10 with no luck on pointer events.  

Pressure from the demo here: https://patrickhlauke.github.io/touch/tracker/tracker-force-pressure.html fails on Chrom 55 but works on Edge.

I have enabled chrome://flags/#enable-pointer-events so that should be turned on. (It was set to Default)

thanks

corban

☆PhistucK

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dave Tapuska]

Yes we can reproduce and are investigating. Please leave your settings at the default settings. Hopefully we will have this cleared up tomorrow when people are back in the office. 

Dave

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dave Tapuska]

We've adjusted the finch study which was forcing it to be disabled in Stable. It should now be enabled; you may have to relaunch Chrome twice (make sure it is fully quit) (once to pull the config down and another to actually run with the new settings).

dave.

[Corban Gossett]

Hey Dave,

So I tried this today and I am running Version 55.0.2883.75 m (64-bit) on a Surface Book running Windows 10. On these two test it's still not working.

https://patrickhlauke.github.io/touch/tracker/tracker-force-pressure.html

https://patrickhlauke.github.io/touch/pen-tracker/

Both give me 0 or .5 for pressure. 

On MS Edge they both work as expected.

I quite Chrome multiple times (and did it again just to be safe) but still no result.  Should I try something else? I also went back to "default" on the #enable-pointer-events flag.

Let me know if I can test anything else to help test this out. We are really excited for this to work.

thanks

corban

--

corban gossett | www.cgossett.com | cor...@cgossett.com | cor...@gmail.com
"I don't mind the pace of life, it's the sudden stop at the end that gets me!"

[PhistucK]

Just some closure to this - Safari 13 ships with pointer events support.

:)

Pointer events are now entirely uncontroversial.

(I wanted to write that it is entirely cross browser, but Firefox is, quite surprisingly, still developing it)

I updated ChromeStatus.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[smaug]

On 12/21/19 12:48 AM, PhistucK wrote:
> Just some closure to this - Safari 13 ships with pointer events support.
> :)
> Pointer events are now entirely uncontroversial.
> (I wanted to write that it is entirely cross browser, but Firefox is, quite surprisingly, still developing it)

Firefox has been shipping pointer events for quite some time, and Fenix is shipping them too.


-Olli

>
> I updated ChromeStatus.
>
> ☆*PhistucK*

>
>
> On Mon, Dec 5, 2016 at 8:45 PM Corban Gossett <cor...@gmail.com <mailto:cor...@gmail.com>> wrote:
>
> Hey Dave,
>
> So I tried this today and I am running Version 55.0.2883.75 m (64-bit) on a Surface Book running Windows 10. On these two test it's still not working.
>
> https://patrickhlauke.github.io/touch/tracker/tracker-force-pressure.html
> https://patrickhlauke.github.io/touch/pen-tracker/
>
> Both give me 0 or .5 for pressure.
>
> On MS Edge they both work as expected.
>
> I quite Chrome multiple times (and did it again just to be safe) but still no result.  Should I try something else? I also went back to "default"
> on the #enable-pointer-events flag.
>
> Let me know if I can test anything else to help test this out. We are really excited for this to work.
>
> thanks
>
> corban
>

> On Mon, Dec 5, 2016 at 10:32 AM, Dave Tapuska <dtap...@chromium.org <mailto:dtap...@chromium.org>> wrote:
>
> We've adjusted the finch study which was forcing it to be disabled in Stable. It should now be enabled; you may have to relaunch Chrome twice
> (make sure it is fully quit) (once to pull the config down and another to actually run with the new settings).
>
> dave.
>

> On Sun, Dec 4, 2016 at 5:09 PM, Dave Tapuska <dtap...@chromium.org <mailto:dtap...@chromium.org>> wrote:
>
> Yes we can reproduce and are investigating. Please leave your settings at the default settings. Hopefully we will have this cleared up
> tomorrow when people are back in the office.
>
> Dave
>

> On Dec 4, 2016 17:02, <cor...@gmail.com <mailto:cor...@gmail.com>> wrote:
>
>
> I also tried the latest Chrome 55 on Windows 10 with no luck on pointer events.
>
> Pressure from the demo here: https://patrickhlauke.github.io/touch/tracker/tracker-force-pressure.html fails on Chrom 55 but works on
> Edge.
>
> I have enabled chrome://flags/#enable-pointer-events so that should be turned on. (It was set to Default)
>
> thanks
>
> corban
>
>
> On Sunday, December 4, 2016 at 12:43:00 PM UTC-8, Rick Byers wrote:
>
> Yikes, it is supposed to be on in 55 AFAIK.  Mustaq?  Finch config issue perhaps?
>
> It appears on by default on Chrome 55 Android (still in beta).
>
> On Dec 4, 2016 8:45 AM, "PhistucK" <phis...@gmail.com> wrote:
>
> I updated Chrome to the latest stable (Chrome 55) on Windows 7 and pointer events seems to be disabled (no PointerEvent on
> window, no onpointermove on document.body), despite the beta blog post announcement.
> The code suggests that it is enabled -
> https://chromium.googlesource.com/chromium/src/+/55.0.2883.75/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in#173
> chrome://flags/#enable-pointer-events is set to Default.
>
> Was it postponed to Chrome 56? Or is it on a high-percentage field trial?
>
>

> ☆*PhistucK*

>
> On Thu, Nov 3, 2016 at 7:27 PM, PhistucK <phis...@gmail.com> wrote:
>

> Please, use crbug.com <http://crbug.com> even for potentional bugs. The intent thread is not the right place anyway.
> Thank you!
>
>
> ☆*PhistucK*

>
> On Thu, Nov 3, 2016 at 7:14 PM, ufabianx via blink-dev <blin...@chromium.org> wrote:
>
> Hello there,
>
> This is Fabian from Drupal, where we recently enabled pointer events via a jQuery binding.
>
> We received bug reports (probably those 1% that have it enabled in stable) of drag and drop being broken in our latest
> stable release, but only on Chrome.
>
> The strange thing is:
>
>    It works in Firefox with the option enabled (and apparently IE 10).
>
> The code to reproduce is:
>
>   jQuery(document).bind('pointermove', function(ev) { console.log(ev.clientX); });
>
> which fails with undefined property.
>
> While obviously:
>
>   jQuery(document).bind('pointermove', function(ev) { console.log(ev.originalEvent.clientX); });
>
> works.
>
> However jQuery (pretty old version though) correctly copies the event.clientX property in Firefox, but fails in
> Chrome. Maybe it cannot detect the mouse event inheritance somehow?
>
> Not sure this is really a bug though, so just reporting the finding here.
>
> Thanks,
>
> Fabian
>
> --
> 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+...@chromium.org.
>
>
>
> --
> 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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.
>
>
>
>
>
> --
> corban gossett | www.cgossett.com <http://www.cgossett.com> | cor...@cgossett.com <mailto:cor...@cgossett.com> | cor...@gmail.com
> <mailto:cor...@gmail.com>

> "I don't mind the pace of life, it's the sudden stop at the end that gets me!"
>

> --
> 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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JV8SigNBBm-eOxH-hrCA3geBEizjvhQuD%3D-g2TkPcn2w%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JV8SigNBBm-eOxH-hrCA3geBEizjvhQuD%3D-g2TkPcn2w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[PhistucK]

Oh, then you might want to update your platform status, it still says "Developing" (maybe because the bug it links to has 24 open dependencies?).

I updated ChromeStatus according to your reply. Thank you!

(I am guessing Fenix is Firefox for Android)

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e308b39b-4b66-637d-e8fe-83170956045b%40welho.com.

[PhistucK]

Help you with what?

☆PhistucK

On Sat, Dec 21, 2019 at 8:51 AM Kiko Rantala <crism...@gmail.com> wrote:

 Helouu can somebody help me please ? , I'm waiting for answering thanks guys :)

Dňa so 21. 12. 2019, 0:19 smaug <sm...@welho.com> napísal(a):

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e308b39b-4b66-637d-e8fe-83170956045b%40welho.com.

[Michaela Merz]

Just wondering .. any event for long click (long press) ?

On Thursday, September 22, 2016 at 10:39:17 AM UTC-5, Mustaq Ahmed wrote:

Contact emails

rby...@chromium.org, mus...@chromium.org

Target

Approval requested for M55.

Spec

https://w3c.github.io/pointerevents/

Summary

The Pointer Events API is a low-level input API for mouse, touch and stylus first introduced by Microsoft and then standardized in the W3C.  The API extends the MouseEvent model to provide an input-modality-agnostic event handling mechanism, covering all uses of Mouse and Touch events.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ODWmcKNQl0I

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

Yes.

Demo link

https://patrickhlauke.github.io/touch/

Debuggability

The PointerEvent API is already supported in devtools.  In particular, console commands getEventListeners(), monitorEvents() and unmonitorEvents() already work for PointerEvents, and the debugging sidebar pane allows setting event listener breakpoints for any/all types of PointerEvents.

Interoperability and Compatibility Risk

IE/Edge: Public support (shipping since IE10)

Firefox: Public support (implementation in progress, available behind a flag)

Safari: Publicly opposed  

Web developers: Mostly positive public support, including jQuery and Dojo.

Interoperability and compatibility risk is low because of following reasons.

1. While implementing, we have been actively engaged with the Pointer Events Working Group, particularly with Microsoft, to address all major technical issues.  For all these issues, either we engaged other vendors to update their implementation & fix the spec accordingly, or changed our implementation to match the spec.  At this point in time, we have only minor/futuristic spec issues to resolve.  This close collaboration with the community helped us come to a consensus on a model for pointer, touch and mouse events that is highly interoperable between Edge, Chrome and Firefox, while remaining compatible with Safari’s implementation of touch and mouse events.  Two major implementation issues have been resolved via breaking spec changes:

1. Implicit Capture for touch is enabled by default, and

2. Boundary Events are not sent during capturing.

2. Although Pointer Events has pretty broad support for many years already, the lack of browser support (other than Edge) raised the bar high for early adaptation.  Our usage stats suggests that ~1% of the pageviews use the API, and most of them use the API in an elementary (i.e. MouseEvent-like) manner.  Our extensive manual compat testing both before & during the Implementation Hackathon with Microsoft, Mozilla & jQuery found no behavioral difference with Edge.

3. Chrome Canary and Dev channels have PointerEvents enabled (100%) via finch since M54.  Chrome Beta and Chrome Stable will also have it enabled for respectively 50% and 1% of our users as M54 rolls out.  We have found a few sites with bugs that are triggered when both touch and pointer events are supported, but these sites are similarly broken on Windows 10 Mobile.  Many sites of this form that were broken in Edge are “fixed” by the removal of the ‘pointerEnabled’ API which was the original recommended way to feature detect for PointerEvents.  We have not yet encountered any site that is broken as a result of the changes to the specification relative to what Edge has already shipped.  If we encounter substantial breakage we’ll circle back with this thread before 55 hits stable.  

[Kiko Rantala]

 Helouu can somebody help me please ? , I'm waiting for answering thanks guys :)

Dňa so 21. 12. 2019, 0:19 smaug <sm...@welho.com> napísal(a):

On 12/21/19 12:48 AM, PhistucK wrote:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e308b39b-4b66-637d-e8fe-83170956045b%40welho.com.

[Rick Byers]

Thanks for the update PhistucK! I agree it's valuable to close the loop on this! To that end (and because I'm procrastinating in trying to catch up on ~3 weeks of e-mail), I'm going to take a bit of a share and share a few  thoughts:

As someone who personally invested hundreds of hours into the "pointer events or not" debate (and changed my mind about it twice, adding lots of delay and frustration), I've felt it worthwhile to do some serious self-reflection. Personally my main takeaway is that I over-indexed on browser engineer design debates (some of which were philosophical) and under-focused on pragmatically providing value to developers. While understanding the concerns and perspectives of each engine is important (eg. we did ultimately come to agree with the hit-testing performance concern WebKit engineers raised to us at the start), there's a real risk of over-indexing on the opinions of browser engineers (including our own) and thereby entirely cutting off potentially useful areas of exploration. We're all human and none of us are very good at predicting the future. Ultimately it's the free market of web developers and framework engineers who will decide which features are useful and how much value there is to end users in preserving the feature in browsers long-term (and for pointer events, we had very strong positive signals from frameworks and other web developers). In the fullness of time we should have some confidence that engines will converge on whether a feature has clearly enough interest and utility for developers to maintain in engines, and the humility to admit where our experiments have failed and invest in cleaning up after them. Of course we still need to honestly appreciate the risks and be responsible in only taking risks which seem justified by the evidence (which is what our API launch process is designed to do), and reasonably mitigate the costs on the platform of our failures.

The other big takeaway for me is that, despite our differences of opinion, it's important to maintain a constructive and respectful working relationship between all browser engineers. Throughout the time WebKit and chromium disagreed on pointer events, we continued to work together on a number of related issues (including a related incremental improvement to touch events!). I suspect that this helped make it easier for Apple to decide to adopt pointer events when conditions changed for them. IMHO, no difference of opinion is worth closing relationship doors for in the relatively small web platform engineer community.

Of course the pointer events saga is far from over. It will still be quite some time before a web page can be written without any need to write code for mouse or touch events. But the fraction of page loads and top sites installing pointer event listeners in Chrome is at about 15% and still climbing steadily, so PointerEvents finally seems like a clear web platform success story. Thank you to everyone who contributed to making it so!

It's interesting to think of the long history of debate around third-party cookies in the above context as well (and how Apple spurred chromium into action via shipping code, rather than via all the political debates). But I think that's where I should draw the line in my post-holiday public musings on web platform controversy ;-).

Rick