Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2217773004:
Added navigator.pointerEnabled behind a flag for experiment. (Closed)
|
Created:
4 years, 4 months ago by mustaq Modified:
4 years, 4 months ago CC:
chromium-reviews, blink-reviews, blink-reviews-bindings_chromium.org, asvitkine+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionAdded navigator.pointerEnabled behind a flag for experiment.
Added navigator.pointerEnabled returning undefined behind the
PointerEvent flag. Also added a counter for its usage.
This is a temporary change to collect usage data of
(non-standard) navigator.pointerEnabled. Edge still
supports the API (desktop only), and some Pointer
Event sites rely on it.
BUG=631897
TBR=isherman@chromium.org
Committed: https://crrev.com/b226b2fff6a3aeeca697ba93d23e579ff873043a
Cr-Commit-Position: refs/heads/master@{#413751}
Patch Set 1 #Patch Set 2 : Added a TODO. #Patch Set 3 : Rebased. #Patch Set 4 : Rebased #Patch Set 5 : Rebased, removed custom binding, fixed a test. #
Total comments: 2
Patch Set 6 : Used default counter name. #Patch Set 7 : Brought back returning undefined, rebased. #Patch Set 8 : |false| again. #
Total comments: 1
Patch Set 9 : Added a warning. #Patch Set 10 : Rebased #
Messages
Total messages: 60 (23 generated)
mustaq@chromium.org changed reviewers: + dtapuska@chromium.org
ptal
mustaq@chromium.org changed reviewers: + dpranke@chromium.org, rbyers@chromium.org
dpranke@chromium.org: Please review changes in Source/{core/bindings}
On 2016/08/05 14:44:05, mustaq wrote:
> mailto:dpranke@chromium.org: Please review changes in Source/{core/bindings}
I wouldn't be a good reviewer for this (I'm not even an owner). Maybe try
haraken@ ?
Do you need the custom bindings? Alternately, can you add an empty implementation to NavigatorEvents.cpp?
On 2016/08/08 23:58:50, haraken wrote: > Do you need the custom bindings? Alternately, can you add an empty > implementation to NavigatorEvents.cpp? Is there a way to return "undefined" thorough an empty implementation in NavigatorEvents? V8 custom binding sets the return value thorugh v8SetReturnValueBool() etc, so not calling this function makes the JS-visible value undefined. On the other hand, NavigatorEvent.cpp expects a bool return value which has to be true or false. We want to keep the value "undefined" so that we don't trigger IE or Edge specific scripts.
The CQ bit was checked by mustaq@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...) cast_shell_android on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...) mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by mustaq@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
On 2016/08/09 14:11:31, mustaq wrote: > On 2016/08/08 23:58:50, haraken wrote: > > Do you need the custom bindings? Alternately, can you add an empty > > implementation to NavigatorEvents.cpp? > > Is there a way to return "undefined" thorough an empty implementation > in NavigatorEvents? V8 custom binding sets the return value thorugh > v8SetReturnValueBool() etc, so not calling this function makes the > JS-visible value undefined. On the other hand, NavigatorEvent.cpp > expects a bool return value which has to be true or false. > > We want to keep the value "undefined" so that we don't trigger IE or > Edge specific scripts. haraken@, are you okay with my explanation above for use of custom binding?
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: ios-simulator on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
On 2016/08/10 16:00:41, mustaq wrote: > On 2016/08/09 14:11:31, mustaq wrote: > > On 2016/08/08 23:58:50, haraken wrote: > > > Do you need the custom bindings? Alternately, can you add an empty > > > implementation to NavigatorEvents.cpp? > > > > Is there a way to return "undefined" thorough an empty implementation > > in NavigatorEvents? V8 custom binding sets the return value thorugh > > v8SetReturnValueBool() etc, so not calling this function makes the > > JS-visible value undefined. On the other hand, NavigatorEvent.cpp > > expects a bool return value which has to be true or false. > > > > We want to keep the value "undefined" so that we don't trigger IE or > > Edge specific scripts. > > haraken@, are you okay with my explanation above for use of custom > binding? Sorry, I missed this review! Even if this is only for measuring UseCounters, it looks like you're doing something very hacky (at least, you're the first person who tries this kind of experiment :-). > > We want to keep the value "undefined" so that we don't trigger IE or > > Edge specific scripts. I'm wondering why you cannot return 'false' from pointerEnabled. I guess that most scripts are using 'if(navigator.pointerEnabled)' to detect features. If that is the case, it won't really matter if we return 'undefined' or 'false', no?
On 2016/08/11 02:02:45, haraken wrote:
> On 2016/08/10 16:00:41, mustaq wrote:
> > On 2016/08/09 14:11:31, mustaq wrote:
> > > On 2016/08/08 23:58:50, haraken wrote:
> > > > Do you need the custom bindings? Alternately, can you add an empty
> > > > implementation to NavigatorEvents.cpp?
> > >
> > > Is there a way to return "undefined" thorough an empty implementation
> > > in NavigatorEvents? V8 custom binding sets the return value thorugh
> > > v8SetReturnValueBool() etc, so not calling this function makes the
> > > JS-visible value undefined. On the other hand, NavigatorEvent.cpp
> > > expects a bool return value which has to be true or false.
> > >
> > > We want to keep the value "undefined" so that we don't trigger IE or
> > > Edge specific scripts.
> >
> > haraken@, are you okay with my explanation above for use of custom
> > binding?
>
> Sorry, I missed this review!
>
> Even if this is only for measuring UseCounters, it looks like you're doing
> something very hacky (at least, you're the first person who tries this kind of
> experiment :-).
>
> > > We want to keep the value "undefined" so that we don't trigger IE or
> > > Edge specific scripts.
>
> I'm wondering why you cannot return 'false' from pointerEnabled. I guess that
> most scripts are using 'if(navigator.pointerEnabled)' to detect features. If
> that is the case, it won't really matter if we return 'undefined' or 'false',
> no?
You are right about the most common feature detection we expect. Through
"undefined", we were hoping to also suppress feature detection like
if ("pointerEnabled" in navigator)
but this seems |true| in the current patch!
Do you know if there's a way to make |"pointerEnabled" in navigator| false
yet use-count?
On 2016/08/11 15:27:39, mustaq wrote:
> On 2016/08/11 02:02:45, haraken wrote:
> > On 2016/08/10 16:00:41, mustaq wrote:
> > > On 2016/08/09 14:11:31, mustaq wrote:
> > > > On 2016/08/08 23:58:50, haraken wrote:
> > > > > Do you need the custom bindings? Alternately, can you add an empty
> > > > > implementation to NavigatorEvents.cpp?
> > > >
> > > > Is there a way to return "undefined" thorough an empty implementation
> > > > in NavigatorEvents? V8 custom binding sets the return value thorugh
> > > > v8SetReturnValueBool() etc, so not calling this function makes the
> > > > JS-visible value undefined. On the other hand, NavigatorEvent.cpp
> > > > expects a bool return value which has to be true or false.
> > > >
> > > > We want to keep the value "undefined" so that we don't trigger IE or
> > > > Edge specific scripts.
> > >
> > > haraken@, are you okay with my explanation above for use of custom
> > > binding?
> >
> > Sorry, I missed this review!
> >
> > Even if this is only for measuring UseCounters, it looks like you're doing
> > something very hacky (at least, you're the first person who tries this kind
of
> > experiment :-).
> >
> > > > We want to keep the value "undefined" so that we don't trigger IE or
> > > > Edge specific scripts.
> >
> > I'm wondering why you cannot return 'false' from pointerEnabled. I guess
that
> > most scripts are using 'if(navigator.pointerEnabled)' to detect features. If
> > that is the case, it won't really matter if we return 'undefined' or
'false',
> > no?
>
> You are right about the most common feature detection we expect. Through
> "undefined", we were hoping to also suppress feature detection like
> if ("pointerEnabled" in navigator)
> but this seems |true| in the current patch!
>
> Do you know if there's a way to make |"pointerEnabled" in navigator| false
> yet use-count?
The only way to do that is not to define pointerEnabled on Navigator.
Overall, I'm feeling that this CL is going in a wrong direction. Maybe should we
reach out to Rick or Foolip if they have any better idea for your purpose?
Description was changed from ========== Added navigator.pointerEnabled that returns undefined. Also added a counter for its usage. BUG=631897 ========== to ========== Added navigator.pointerEnabled that returns undefined. Also added a counter for its usage. BUG=631897 ==========
mustaq@chromium.org changed reviewers: + foolip@chromium.org
On 2016/08/11 15:38:42, haraken wrote:
> On 2016/08/11 15:27:39, mustaq wrote:
> > On 2016/08/11 02:02:45, haraken wrote:
> > > On 2016/08/10 16:00:41, mustaq wrote:
> > > > On 2016/08/09 14:11:31, mustaq wrote:
> > > > > On 2016/08/08 23:58:50, haraken wrote:
> > > > > > Do you need the custom bindings? Alternately, can you add an empty
> > > > > > implementation to NavigatorEvents.cpp?
> > > > >
> > > > > Is there a way to return "undefined" thorough an empty implementation
> > > > > in NavigatorEvents? V8 custom binding sets the return value thorugh
> > > > > v8SetReturnValueBool() etc, so not calling this function makes the
> > > > > JS-visible value undefined. On the other hand, NavigatorEvent.cpp
> > > > > expects a bool return value which has to be true or false.
> > > > >
> > > > > We want to keep the value "undefined" so that we don't trigger IE or
> > > > > Edge specific scripts.
> > > >
> > > > haraken@, are you okay with my explanation above for use of custom
> > > > binding?
> > >
> > > Sorry, I missed this review!
> > >
> > > Even if this is only for measuring UseCounters, it looks like you're doing
> > > something very hacky (at least, you're the first person who tries this
kind
> of
> > > experiment :-).
> > >
> > > > > We want to keep the value "undefined" so that we don't trigger IE or
> > > > > Edge specific scripts.
> > >
> > > I'm wondering why you cannot return 'false' from pointerEnabled. I guess
> that
> > > most scripts are using 'if(navigator.pointerEnabled)' to detect features.
If
> > > that is the case, it won't really matter if we return 'undefined' or
> 'false',
> > > no?
> >
> > You are right about the most common feature detection we expect. Through
> > "undefined", we were hoping to also suppress feature detection like
> > if ("pointerEnabled" in navigator)
> > but this seems |true| in the current patch!
> >
> > Do you know if there's a way to make |"pointerEnabled" in navigator| false
> > yet use-count?
>
> The only way to do that is not to define pointerEnabled on Navigator.
>
> Overall, I'm feeling that this CL is going in a wrong direction. Maybe should
we
> reach out to Rick or Foolip if they have any better idea for your purpose?
A quick regexp search in httparchive for
r"[\"\']pointerEnabled[\"\'][^\w]+in[^\w]+navigator"
found only two instances, therefore the simplest solution with |false| is good
enough.
Philip/Dave: Since Rick is out and we want to start tracking the count soon, I
will ask for
a second opinion.
On 2016/08/11 15:54:04, mustaq wrote:
> On 2016/08/11 15:38:42, haraken wrote:
> > On 2016/08/11 15:27:39, mustaq wrote:
> > > On 2016/08/11 02:02:45, haraken wrote:
> > > > On 2016/08/10 16:00:41, mustaq wrote:
> > > > > On 2016/08/09 14:11:31, mustaq wrote:
> > > > > > On 2016/08/08 23:58:50, haraken wrote:
> > > > > > > Do you need the custom bindings? Alternately, can you add an empty
> > > > > > > implementation to NavigatorEvents.cpp?
> > > > > >
> > > > > > Is there a way to return "undefined" thorough an empty
implementation
> > > > > > in NavigatorEvents? V8 custom binding sets the return value thorugh
> > > > > > v8SetReturnValueBool() etc, so not calling this function makes the
> > > > > > JS-visible value undefined. On the other hand, NavigatorEvent.cpp
> > > > > > expects a bool return value which has to be true or false.
> > > > > >
> > > > > > We want to keep the value "undefined" so that we don't trigger IE or
> > > > > > Edge specific scripts.
> > > > >
> > > > > haraken@, are you okay with my explanation above for use of custom
> > > > > binding?
> > > >
> > > > Sorry, I missed this review!
> > > >
> > > > Even if this is only for measuring UseCounters, it looks like you're
doing
> > > > something very hacky (at least, you're the first person who tries this
> kind
> > of
> > > > experiment :-).
> > > >
> > > > > > We want to keep the value "undefined" so that we don't trigger IE or
> > > > > > Edge specific scripts.
> > > >
> > > > I'm wondering why you cannot return 'false' from pointerEnabled. I guess
> > that
> > > > most scripts are using 'if(navigator.pointerEnabled)' to detect
features.
> If
> > > > that is the case, it won't really matter if we return 'undefined' or
> > 'false',
> > > > no?
> > >
> > > You are right about the most common feature detection we expect. Through
> > > "undefined", we were hoping to also suppress feature detection like
> > > if ("pointerEnabled" in navigator)
> > > but this seems |true| in the current patch!
> > >
> > > Do you know if there's a way to make |"pointerEnabled" in navigator| false
> > > yet use-count?
> >
> > The only way to do that is not to define pointerEnabled on Navigator.
> >
> > Overall, I'm feeling that this CL is going in a wrong direction. Maybe
should
> we
> > reach out to Rick or Foolip if they have any better idea for your purpose?
>
> A quick regexp search in httparchive for
> r"[\"\']pointerEnabled[\"\'][^\w]+in[^\w]+navigator"
> found only two instances, therefore the simplest solution with |false| is good
> enough.
>
> Philip/Dave: Since Rick is out and we want to start tracking the count soon, I
> will ask for
> a second opinion.
Ya let's just go with the false for now we've been punting on this far too long
and we need to gather the data.
Description was changed from ========== Added navigator.pointerEnabled that returns undefined. Also added a counter for its usage. BUG=631897 ========== to ========== Added navigator.pointerEnabled that returns false. Also added a counter for its usage. This is a temporary change to collect usage data of (non-standard) navigator.pointerEnabled. Edge still supports the API (desktop only), and some Pointer Event sites rely on it. BUG=631897 ==========
ptal, switched to returning |false|.
Not sure about this, there's a good chance you'll see high usage simply by scripts enumerating all of navigator for stats, fingerprinting or something similar. Of the things already measured on navigator, this is the lowest: https://www.chromestatus.com/metrics/feature/timeline/popularity/125 This is a problem for all attributes on common interfaces. What would it take to implement this in the same way that Edge does? I'd say that an httparchive search to identify sites and libraries that would start to work better with an implementation of this would be more valuable than a use counter showing 0.1% or some such usage. If the implementation would be trivial and there are sites using it, then it seems like an easy argument for having it spec'd and shipped. https://codereview.chromium.org/2217773004/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/events/NavigatorEvents.idl (right): https://codereview.chromium.org/2217773004/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/events/NavigatorEvents.idl:39: [RuntimeEnabled=PointerEvent,MeasureAs=NavigatorPointerEnabled] readonly attribute boolean pointerEnabled; You can use just [Measure] to get the generated name.
On 2016/08/11 21:14:32, foolip wrote: > Not sure about this, there's a good chance you'll see high usage simply by > scripts enumerating all of navigator for stats, fingerprinting or something > similar. Of the things already measured on navigator, this is the lowest: > https://www.chromestatus.com/metrics/feature/timeline/popularity/125 > > This is a problem for all attributes on common interfaces. > > What would it take to implement this in the same way that Edge does? > > I'd say that an httparchive search to identify sites and libraries that would > start to work better with an implementation of this would be more valuable than > a use counter showing 0.1% or some such usage. If the implementation would be > trivial and there are sites using it, then it seems like an easy argument for > having it spec'd and shipped. > > https://codereview.chromium.org/2217773004/diff/80001/third_party/WebKit/Sour... > File third_party/WebKit/Source/core/events/NavigatorEvents.idl (right): > > https://codereview.chromium.org/2217773004/diff/80001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/events/NavigatorEvents.idl:39: > [RuntimeEnabled=PointerEvent,MeasureAs=NavigatorPointerEnabled] readonly > attribute boolean pointerEnabled; > You can use just [Measure] to get the generated name. I thought there was a way to hide it from the enumeration. My ideal scenario is to have it return undefined and don't have it in the enumeration. So we just see people querying the value by direct access.
On 2016/08/11 22:44:18, dtapuska wrote: > I thought there was a way to hide it from the enumeration. My ideal scenario is > to have it return undefined and don't have it in the enumeration. So we just see > people querying the value by direct access. Just drop-by, so I don't understand the details or background. Did you mean [NotEnumerable] extended attribute?
On 2016/08/12 06:57:42, Yuki wrote: > On 2016/08/11 22:44:18, dtapuska wrote: > > I thought there was a way to hide it from the enumeration. My ideal scenario > is > > to have it return undefined and don't have it in the enumeration. So we just > see > > people querying the value by direct access. > > Just drop-by, so I don't understand the details or background. > Did you mean [NotEnumerable] extended attribute? Even that won't quite do the trick, because getOwnPropertyNames will still find it. I am interested to know what reasons you already have for thinking that this attribute is needed. It could be that the reasons are already strong enough to just do it, instead of waiting for use counter data and still not finding anything conclusive.
On 2016/08/12 11:12:04, foolip wrote: > On 2016/08/12 06:57:42, Yuki wrote: > > On 2016/08/11 22:44:18, dtapuska wrote: > > > I thought there was a way to hide it from the enumeration. My ideal scenario > > is > > > to have it return undefined and don't have it in the enumeration. So we just > > see > > > people querying the value by direct access. > > > > Just drop-by, so I don't understand the details or background. > > Did you mean [NotEnumerable] extended attribute? > > Even that won't quite do the trick, because getOwnPropertyNames will still find > it. > > I am interested to know what reasons you already have for thinking that this > attribute is needed. It could be that the reasons are already strong enough to > just do it, instead of waiting for use counter data and still not finding > anything conclusive. Here is the main motivation, this came up at the PE Hackathon at Microsoft few weeks ago: we want to understand the web compat implications of the proposed Chrome model for PointerEvents (touch capture is implicit, circumvents hit-testing). For that, we would like to find as many sites as possible using touch capturing. The PE usage fractions we are seeing are much smaller than what Edge does: Chrome for Windows finds ~1% of the page views install a PE listener, while Edge finds ~15%. We hypothesized that many sites could be using the non-standard navigator.pointerEnabled API (still supported by Edge)---we need numbers to support our hypothesis. https://docs.google.com/document/d/1b8aJOJcGXakstFJslKl87QwvlFHhHwGbQfJwnUTBB... If we are right, we would see numbers much higher than the lowest Navigator attribute count. We can even ignore the part of the count triggered by getOwnPropertyNames by deducting the count for NavigatorVendorSub. Seems [NotEnumerable] does the trick for us then, right? Should I go ahead with it?
ptal. The attribute is now not visible through for...in loops. https://codereview.chromium.org/2217773004/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/events/NavigatorEvents.idl (right): https://codereview.chromium.org/2217773004/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/events/NavigatorEvents.idl:39: [RuntimeEnabled=PointerEvent,MeasureAs=NavigatorPointerEnabled] readonly attribute boolean pointerEnabled; On 2016/08/11 21:14:32, foolip wrote: > You can use just [Measure] to get the generated name. Done.
yukishiino@chromium.org changed reviewers: + yukishiino@chromium.org
LGTM on my side.
In terms of bindings implementation, looks good. However, I'm not sure if this is an expected way to measure a potential risk of non-standard DOM attributes. I'll defer the decision to foolip@.
On 2016/08/12 15:09:40, mustaq wrote: > On 2016/08/12 11:12:04, foolip wrote: > > On 2016/08/12 06:57:42, Yuki wrote: > > > On 2016/08/11 22:44:18, dtapuska wrote: > > > > I thought there was a way to hide it from the enumeration. My ideal > scenario > > > is > > > > to have it return undefined and don't have it in the enumeration. So we > just > > > see > > > > people querying the value by direct access. > > > > > > Just drop-by, so I don't understand the details or background. > > > Did you mean [NotEnumerable] extended attribute? > > > > Even that won't quite do the trick, because getOwnPropertyNames will still > find > > it. > > > > I am interested to know what reasons you already have for thinking that this > > attribute is needed. It could be that the reasons are already strong enough to > > just do it, instead of waiting for use counter data and still not finding > > anything conclusive. > > Here is the main motivation, this came up at the PE Hackathon at Microsoft few > weeks ago: we want to understand the web compat implications of the proposed > Chrome model for PointerEvents (touch capture is implicit, circumvents > hit-testing). For that, we would like to find as many sites as possible using > touch capturing. The PE usage fractions we are seeing are much smaller than what > Edge does: Chrome for Windows finds ~1% of the page views install a PE listener, > while Edge finds ~15%. We hypothesized that many sites could be using the > non-standard navigator.pointerEnabled API (still supported by Edge)---we need > numbers to support our hypothesis. > > https://docs.google.com/document/d/1b8aJOJcGXakstFJslKl87QwvlFHhHwGbQfJwnUTBB... > > If we are right, we would see numbers much higher than the lowest Navigator > attribute count. > > We can even ignore the part of the count triggered by getOwnPropertyNames by > deducting the count for NavigatorVendorSub. > > Seems [NotEnumerable] does the trick for us then, right? Should I go ahead with > it? Is it https://www.chromestatus.com/metrics/feature/timeline/popularity/1347 you're looking at, and is the Edge counter for precisely the same thing? We know that use counter is broken on fast shutdown and there could be other reasons to the discrepancy, but 1% vs. 15% still sounds like a lot. I did `SELECT page,url FROM [httparchive:har.2016_06_15_chrome_requests_bodies] WHERE body CONTAINS 'pointerEnabled';` in BigQuery and there were 51363 results. I haven't yet figured out how to further analyze results in BigQuery, but looking at the first few pages, I see these things popping up a lot: https://github.com/mattbryson/TouchSwipe-Jquery-Plugin/blob/master/jquery.tou... (jquery.themepunch.tools.min.js includes this) https://f.vimeocdn.com/p/2.26.5/js/player.js https://github.com/nolimits4web/Swiper http://www.jssor.com/ This pattern could explain it: https://github.com/nolimits4web/Swiper/blob/bd6921a556fb92b5ab87601f99bebffcd... if (window.navigator.pointerEnabled) s.touchEventsDesktop = {start: 'pointerdown', move: 'pointermove', end: 'pointerup'}; else if (window.navigator.msPointerEnabled) s.touchEventsDesktop = {start: 'MSPointerDown', move: 'MSPointerMove', end: 'MSPointerUp'}; Taking a closer look at httparchive results might be interesting. If this looks like the common case, then you may learn what you need in a matter of hours instead of waiting for 6+ weeks for use counter data. I'm getting on a plane now, but I'm a bit worried about adding pointerEnabled for measurement purposes. There just isn't a way to measure this without also potentially affecting behavior ('pointerEvent' in navigator) so if you think that adding support for pointerEnabled is at all a good idea, then just having it return true and letting it be enumerable from the start might be safer, i.e. matching exactly what Edge does so you hit all the same code paths.
On 2016/08/15 14:49:31, foolip wrote: > On 2016/08/12 15:09:40, mustaq wrote: > > On 2016/08/12 11:12:04, foolip wrote: > > > On 2016/08/12 06:57:42, Yuki wrote: > > > > On 2016/08/11 22:44:18, dtapuska wrote: > > > > > I thought there was a way to hide it from the enumeration. My ideal > > scenario > > > > is > > > > > to have it return undefined and don't have it in the enumeration. So we > > just > > > > see > > > > > people querying the value by direct access. > > > > > > > > Just drop-by, so I don't understand the details or background. > > > > Did you mean [NotEnumerable] extended attribute? > > > > > > Even that won't quite do the trick, because getOwnPropertyNames will still > > find > > > it. > > > > > > I am interested to know what reasons you already have for thinking that this > > > attribute is needed. It could be that the reasons are already strong enough > to > > > just do it, instead of waiting for use counter data and still not finding > > > anything conclusive. > > > > Here is the main motivation, this came up at the PE Hackathon at Microsoft few > > weeks ago: we want to understand the web compat implications of the proposed > > Chrome model for PointerEvents (touch capture is implicit, circumvents > > hit-testing). For that, we would like to find as many sites as possible using > > touch capturing. The PE usage fractions we are seeing are much smaller than > what > > Edge does: Chrome for Windows finds ~1% of the page views install a PE > listener, > > while Edge finds ~15%. We hypothesized that many sites could be using the > > non-standard navigator.pointerEnabled API (still supported by Edge)---we need > > numbers to support our hypothesis. > > > > > https://docs.google.com/document/d/1b8aJOJcGXakstFJslKl87QwvlFHhHwGbQfJwnUTBB... > > > > If we are right, we would see numbers much higher than the lowest Navigator > > attribute count. > > > > We can even ignore the part of the count triggered by getOwnPropertyNames by > > deducting the count for NavigatorVendorSub. > > > > Seems [NotEnumerable] does the trick for us then, right? Should I go ahead > with > > it? > > Is it https://www.chromestatus.com/metrics/feature/timeline/popularity/1347 > you're looking at, and is the Edge counter for precisely the same thing? We know > that use counter is broken on fast shutdown and there could be other reasons to > the discrepancy, but 1% vs. 15% still sounds like a lot. > > I did `SELECT page,url FROM [httparchive:har.2016_06_15_chrome_requests_bodies] > WHERE body CONTAINS 'pointerEnabled';` in BigQuery and there were 51363 results. > I haven't yet figured out how to further analyze results in BigQuery, but > looking at the first few pages, I see these things popping up a lot: > https://github.com/mattbryson/TouchSwipe-Jquery-Plugin/blob/master/jquery.tou... > (jquery.themepunch.tools.min.js includes this) > https://f.vimeocdn.com/p/2.26.5/js/player.js > https://github.com/nolimits4web/Swiper > http://www.jssor.com/ > > This pattern could explain it: > https://github.com/nolimits4web/Swiper/blob/bd6921a556fb92b5ab87601f99bebffcd... > > if (window.navigator.pointerEnabled) s.touchEventsDesktop = {start: > 'pointerdown', move: 'pointermove', end: 'pointerup'}; > else if (window.navigator.msPointerEnabled) s.touchEventsDesktop = {start: > 'MSPointerDown', move: 'MSPointerMove', end: 'MSPointerUp'}; > > Taking a closer look at httparchive results might be interesting. If this looks > like the common case, then you may learn what you need in a matter of hours > instead of waiting for 6+ weeks for use counter data. > > I'm getting on a plane now, but I'm a bit worried about adding pointerEnabled > for measurement purposes. There just isn't a way to measure this without also > potentially affecting behavior ('pointerEvent' in navigator) so if you think > that adding support for pointerEnabled is at all a good idea, then just having > it return true and letting it be enumerable from the start might be safer, i.e. > matching exactly what Edge does so you hit all the same code paths. Edge changes the way the field reports based on mobile or desktop. (depending on if they have touch events enabled; they found touch events were more reliably written on the web vs pointer events). I think this was rbyers@ idea to report it as undefined.
On 2016/08/15 14:54:01, dtapuska wrote: > On 2016/08/15 14:49:31, foolip wrote: > > On 2016/08/12 15:09:40, mustaq wrote: > > > On 2016/08/12 11:12:04, foolip wrote: > > > > On 2016/08/12 06:57:42, Yuki wrote: > > > > > On 2016/08/11 22:44:18, dtapuska wrote: > > > > > > I thought there was a way to hide it from the enumeration. My ideal > > > scenario > > > > > is > > > > > > to have it return undefined and don't have it in the enumeration. So > we > > > just > > > > > see > > > > > > people querying the value by direct access. > > > > > > > > > > Just drop-by, so I don't understand the details or background. > > > > > Did you mean [NotEnumerable] extended attribute? > > > > > > > > Even that won't quite do the trick, because getOwnPropertyNames will still > > > find > > > > it. > > > > > > > > I am interested to know what reasons you already have for thinking that > this > > > > attribute is needed. It could be that the reasons are already strong > enough > > to > > > > just do it, instead of waiting for use counter data and still not finding > > > > anything conclusive. > > > > > > Here is the main motivation, this came up at the PE Hackathon at Microsoft > few > > > weeks ago: we want to understand the web compat implications of the proposed > > > Chrome model for PointerEvents (touch capture is implicit, circumvents > > > hit-testing). For that, we would like to find as many sites as possible > using > > > touch capturing. The PE usage fractions we are seeing are much smaller than > > what > > > Edge does: Chrome for Windows finds ~1% of the page views install a PE > > listener, > > > while Edge finds ~15%. We hypothesized that many sites could be using the > > > non-standard navigator.pointerEnabled API (still supported by Edge)---we > need > > > numbers to support our hypothesis. > > > > > > > > > https://docs.google.com/document/d/1b8aJOJcGXakstFJslKl87QwvlFHhHwGbQfJwnUTBB... > > > > > > If we are right, we would see numbers much higher than the lowest Navigator > > > attribute count. > > > > > > We can even ignore the part of the count triggered by getOwnPropertyNames by > > > deducting the count for NavigatorVendorSub. > > > > > > Seems [NotEnumerable] does the trick for us then, right? Should I go ahead > > with > > > it? > > > > Is it https://www.chromestatus.com/metrics/feature/timeline/popularity/1347 > > you're looking at, and is the Edge counter for precisely the same thing? We > know > > that use counter is broken on fast shutdown and there could be other reasons > to > > the discrepancy, but 1% vs. 15% still sounds like a lot. We don't have any insight if the Edge stats came from counters or not. As Dave mentioned, their navigator.pointerEnabled varies with mobile vs desktop, so a similar counter won't make much sense on their side. > > > > I did `SELECT page,url FROM > [httparchive:har.2016_06_15_chrome_requests_bodies] > > WHERE body CONTAINS 'pointerEnabled';` in BigQuery and there were 51363 > results. > > I haven't yet figured out how to further analyze results in BigQuery, but > > looking at the first few pages, I see these things popping up a lot: > > > https://github.com/mattbryson/TouchSwipe-Jquery-Plugin/blob/master/jquery.tou... > > (jquery.themepunch.tools.min.js includes this) > > https://f.vimeocdn.com/p/2.26.5/js/player.js > > https://github.com/nolimits4web/Swiper > > http://www.jssor.com/ > > > > This pattern could explain it: > > > https://github.com/nolimits4web/Swiper/blob/bd6921a556fb92b5ab87601f99bebffcd... > > > > if (window.navigator.pointerEnabled) s.touchEventsDesktop = {start: > > 'pointerdown', move: 'pointermove', end: 'pointerup'}; > > else if (window.navigator.msPointerEnabled) s.touchEventsDesktop = {start: > > 'MSPointerDown', move: 'MSPointerMove', end: 'MSPointerUp'}; > > > > Taking a closer look at httparchive results might be interesting. If this > looks > > like the common case, then you may learn what you need in a matter of hours > > instead of waiting for 6+ weeks for use counter data. I just ran another httparchive query to rule out MS-prefixed pointerEnabled: ...WHERE REGEXP_MATCH(body, r"[^Mm][^Ss]pointerEnabled") Result: 49,649 hits in 18,738,746 input rows (~0.25%). We agree that this sets an upperbound on the number of sites using pointerEnabled API. But the fraction of pages using the API /that users interact with/ could be totally different: e.g. if many of those 0.25% are really popular, the fraction of pages hit would be higher. > > > > I'm getting on a plane now, but I'm a bit worried about adding pointerEnabled > > for measurement purposes. There just isn't a way to measure this without also > > potentially affecting behavior ('pointerEvent' in navigator) so if you think > > that adding support for pointerEnabled is at all a good idea, then just having > > it return true and letting it be enumerable from the start might be safer, > i.e. > > matching exactly what Edge does so you hit all the same code paths. > > Edge changes the way the field reports based on mobile or desktop. (depending on > if they have touch events enabled; they found touch events were more reliably > written on the web vs pointer events). I think this was rbyers@ idea to report > it as undefined. Are you okay if we land returning |false| for now? We will definitely revisit our decision next week after Rick comes back from vacation. The risks from the behind-the-flag value (whatever it is) is pretty low.
On 2016/08/15 17:11:13, mustaq wrote: > On 2016/08/15 14:54:01, dtapuska wrote: > > On 2016/08/15 14:49:31, foolip wrote: > > > On 2016/08/12 15:09:40, mustaq wrote: > > > > On 2016/08/12 11:12:04, foolip wrote: > > > > > On 2016/08/12 06:57:42, Yuki wrote: > > > > > > On 2016/08/11 22:44:18, dtapuska wrote: > > > > > > > I thought there was a way to hide it from the enumeration. My ideal > > > > scenario > > > > > > is > > > > > > > to have it return undefined and don't have it in the enumeration. So > > we > > > > just > > > > > > see > > > > > > > people querying the value by direct access. > > > > > > > > > > > > Just drop-by, so I don't understand the details or background. > > > > > > Did you mean [NotEnumerable] extended attribute? > > > > > > > > > > Even that won't quite do the trick, because getOwnPropertyNames will > still > > > > find > > > > > it. > > > > > > > > > > I am interested to know what reasons you already have for thinking that > > this > > > > > attribute is needed. It could be that the reasons are already strong > > enough > > > to > > > > > just do it, instead of waiting for use counter data and still not > finding > > > > > anything conclusive. > > > > > > > > Here is the main motivation, this came up at the PE Hackathon at Microsoft > > few > > > > weeks ago: we want to understand the web compat implications of the > proposed > > > > Chrome model for PointerEvents (touch capture is implicit, circumvents > > > > hit-testing). For that, we would like to find as many sites as possible > > using > > > > touch capturing. The PE usage fractions we are seeing are much smaller > than > > > what > > > > Edge does: Chrome for Windows finds ~1% of the page views install a PE > > > listener, > > > > while Edge finds ~15%. We hypothesized that many sites could be using the > > > > non-standard navigator.pointerEnabled API (still supported by Edge)---we > > need > > > > numbers to support our hypothesis. > > > > > > > > > > > > > > https://docs.google.com/document/d/1b8aJOJcGXakstFJslKl87QwvlFHhHwGbQfJwnUTBB... > > > > > > > > If we are right, we would see numbers much higher than the lowest > Navigator > > > > attribute count. > > > > > > > > We can even ignore the part of the count triggered by getOwnPropertyNames > by > > > > deducting the count for NavigatorVendorSub. > > > > > > > > Seems [NotEnumerable] does the trick for us then, right? Should I go ahead > > > with > > > > it? > > > > > > Is it https://www.chromestatus.com/metrics/feature/timeline/popularity/1347 > > > you're looking at, and is the Edge counter for precisely the same thing? We > > know > > > that use counter is broken on fast shutdown and there could be other reasons > > to > > > the discrepancy, but 1% vs. 15% still sounds like a lot. > > We don't have any insight if the Edge stats came from counters or not. As Dave > mentioned, their navigator.pointerEnabled varies with mobile vs desktop, so a > similar counter won't make much sense on their side. > > > > > > > I did `SELECT page,url FROM > > [httparchive:har.2016_06_15_chrome_requests_bodies] > > > WHERE body CONTAINS 'pointerEnabled';` in BigQuery and there were 51363 > > results. > > > I haven't yet figured out how to further analyze results in BigQuery, but > > > looking at the first few pages, I see these things popping up a lot: > > > > > > https://github.com/mattbryson/TouchSwipe-Jquery-Plugin/blob/master/jquery.tou... > > > (jquery.themepunch.tools.min.js includes this) > > > https://f.vimeocdn.com/p/2.26.5/js/player.js > > > https://github.com/nolimits4web/Swiper > > > http://www.jssor.com/ > > > > > > This pattern could explain it: > > > > > > https://github.com/nolimits4web/Swiper/blob/bd6921a556fb92b5ab87601f99bebffcd... > > > > > > if (window.navigator.pointerEnabled) s.touchEventsDesktop = {start: > > > 'pointerdown', move: 'pointermove', end: 'pointerup'}; > > > else if (window.navigator.msPointerEnabled) s.touchEventsDesktop = {start: > > > 'MSPointerDown', move: 'MSPointerMove', end: 'MSPointerUp'}; > > > > > > Taking a closer look at httparchive results might be interesting. If this > > looks > > > like the common case, then you may learn what you need in a matter of hours > > > instead of waiting for 6+ weeks for use counter data. > > I just ran another httparchive query to rule out MS-prefixed pointerEnabled: > ...WHERE REGEXP_MATCH(body, r"[^Mm][^Ss]pointerEnabled") > > Result: 49,649 hits in 18,738,746 input rows (~0.25%). > > We agree that this sets an upperbound on the number of sites using > pointerEnabled > API. But the fraction of pages using the API /that users interact with/ could be > totally different: e.g. if many of those 0.25% are really popular, the fraction > of pages hit would be higher. > > > > > > > I'm getting on a plane now, but I'm a bit worried about adding > pointerEnabled > > > for measurement purposes. There just isn't a way to measure this without > also > > > potentially affecting behavior ('pointerEvent' in navigator) so if you think > > > that adding support for pointerEnabled is at all a good idea, then just > having > > > it return true and letting it be enumerable from the start might be safer, > > i.e. > > > matching exactly what Edge does so you hit all the same code paths. > > > > Edge changes the way the field reports based on mobile or desktop. (depending > on > > if they have touch events enabled; they found touch events were more reliably > > written on the web vs pointer events). I think this was rbyers@ idea to report > > it as undefined. > > Are you okay if we land returning |false| for now? We will definitely revisit > our > decision next week after Rick comes back from vacation. The risks from > the behind-the-flag value (whatever it is) is pretty low. Given that this API is only part of the Pointer Events experiment (and will never be shipped to stable) I think the risk is relatively low (certainly much lower than the compat risk of just having the PE APIs at all). And yes, we really do want dynamic data here - not just httparchive (Microsoft already has lots of static data on this property usage from their crawler, they said they'd really like to know what that boils down to in practice in real-world usage). But I'd prefer to return 'undefined' instead of 'false' just because that makes a bit more sense and is less likely to confuse developers (we're not actually claiming we don't support pointer events).
On 2016/08/22 13:53:06, Rick Byers wrote: > On 2016/08/15 17:11:13, mustaq wrote: > > On 2016/08/15 14:54:01, dtapuska wrote: > > > On 2016/08/15 14:49:31, foolip wrote: > > > > On 2016/08/12 15:09:40, mustaq wrote: > > > > > On 2016/08/12 11:12:04, foolip wrote: > > > > > > On 2016/08/12 06:57:42, Yuki wrote: > > > > > > > On 2016/08/11 22:44:18, dtapuska wrote: > > > > > > > > I thought there was a way to hide it from the enumeration. My > ideal > > > > > scenario > > > > > > > is > > > > > > > > to have it return undefined and don't have it in the enumeration. > So > > > we > > > > > just > > > > > > > see > > > > > > > > people querying the value by direct access. > > > > > > > > > > > > > > Just drop-by, so I don't understand the details or background. > > > > > > > Did you mean [NotEnumerable] extended attribute? > > > > > > > > > > > > Even that won't quite do the trick, because getOwnPropertyNames will > > still > > > > > find > > > > > > it. > > > > > > > > > > > > I am interested to know what reasons you already have for thinking > that > > > this > > > > > > attribute is needed. It could be that the reasons are already strong > > > enough > > > > to > > > > > > just do it, instead of waiting for use counter data and still not > > finding > > > > > > anything conclusive. > > > > > > > > > > Here is the main motivation, this came up at the PE Hackathon at > Microsoft > > > few > > > > > weeks ago: we want to understand the web compat implications of the > > proposed > > > > > Chrome model for PointerEvents (touch capture is implicit, circumvents > > > > > hit-testing). For that, we would like to find as many sites as possible > > > using > > > > > touch capturing. The PE usage fractions we are seeing are much smaller > > than > > > > what > > > > > Edge does: Chrome for Windows finds ~1% of the page views install a PE > > > > listener, > > > > > while Edge finds ~15%. We hypothesized that many sites could be using > the > > > > > non-standard navigator.pointerEnabled API (still supported by Edge)---we > > > need > > > > > numbers to support our hypothesis. > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1b8aJOJcGXakstFJslKl87QwvlFHhHwGbQfJwnUTBB... > > > > > > > > > > If we are right, we would see numbers much higher than the lowest > > Navigator > > > > > attribute count. > > > > > > > > > > We can even ignore the part of the count triggered by > getOwnPropertyNames > > by > > > > > deducting the count for NavigatorVendorSub. > > > > > > > > > > Seems [NotEnumerable] does the trick for us then, right? Should I go > ahead > > > > with > > > > > it? > > > > > > > > Is it > https://www.chromestatus.com/metrics/feature/timeline/popularity/1347 > > > > you're looking at, and is the Edge counter for precisely the same thing? > We > > > know > > > > that use counter is broken on fast shutdown and there could be other > reasons > > > to > > > > the discrepancy, but 1% vs. 15% still sounds like a lot. > > > > We don't have any insight if the Edge stats came from counters or not. As Dave > > mentioned, their navigator.pointerEnabled varies with mobile vs desktop, so a > > similar counter won't make much sense on their side. > > > > > > > > > > I did `SELECT page,url FROM > > > [httparchive:har.2016_06_15_chrome_requests_bodies] > > > > WHERE body CONTAINS 'pointerEnabled';` in BigQuery and there were 51363 > > > results. > > > > I haven't yet figured out how to further analyze results in BigQuery, but > > > > looking at the first few pages, I see these things popping up a lot: > > > > > > > > > > https://github.com/mattbryson/TouchSwipe-Jquery-Plugin/blob/master/jquery.tou... > > > > (jquery.themepunch.tools.min.js includes this) > > > > https://f.vimeocdn.com/p/2.26.5/js/player.js > > > > https://github.com/nolimits4web/Swiper > > > > http://www.jssor.com/ > > > > > > > > This pattern could explain it: > > > > > > > > > > https://github.com/nolimits4web/Swiper/blob/bd6921a556fb92b5ab87601f99bebffcd... > > > > > > > > if (window.navigator.pointerEnabled) s.touchEventsDesktop = {start: > > > > 'pointerdown', move: 'pointermove', end: 'pointerup'}; > > > > else if (window.navigator.msPointerEnabled) s.touchEventsDesktop = {start: > > > > 'MSPointerDown', move: 'MSPointerMove', end: 'MSPointerUp'}; > > > > > > > > Taking a closer look at httparchive results might be interesting. If this > > > looks > > > > like the common case, then you may learn what you need in a matter of > hours > > > > instead of waiting for 6+ weeks for use counter data. > > > > I just ran another httparchive query to rule out MS-prefixed pointerEnabled: > > ...WHERE REGEXP_MATCH(body, r"[^Mm][^Ss]pointerEnabled") > > > > Result: 49,649 hits in 18,738,746 input rows (~0.25%). > > > > We agree that this sets an upperbound on the number of sites using > > pointerEnabled > > API. But the fraction of pages using the API /that users interact with/ could > be > > totally different: e.g. if many of those 0.25% are really popular, the > fraction > > of pages hit would be higher. > > > > > > > > > > I'm getting on a plane now, but I'm a bit worried about adding > > pointerEnabled > > > > for measurement purposes. There just isn't a way to measure this without > > also > > > > potentially affecting behavior ('pointerEvent' in navigator) so if you > think > > > > that adding support for pointerEnabled is at all a good idea, then just > > having > > > > it return true and letting it be enumerable from the start might be safer, > > > i.e. > > > > matching exactly what Edge does so you hit all the same code paths. > > > > > > Edge changes the way the field reports based on mobile or desktop. > (depending > > on > > > if they have touch events enabled; they found touch events were more > reliably > > > written on the web vs pointer events). I think this was rbyers@ idea to > report > > > it as undefined. > > > > Are you okay if we land returning |false| for now? We will definitely revisit > > our > > decision next week after Rick comes back from vacation. The risks from > > the behind-the-flag value (whatever it is) is pretty low. > > Given that this API is only part of the Pointer Events experiment (and will > never be shipped to stable) I think the risk is relatively low (certainly much > lower than the compat risk of just having the PE APIs at all). Maybe update the CL title and/or description to make it clear this isn't a shipping API? Just a temporary experiment behind the PointerEvent RuntimeEnabledFeature? > And yes, we > really do want dynamic data here - not just httparchive (Microsoft already has > lots of static data on this property usage from their crawler, they said they'd > really like to know what that boils down to in practice in real-world usage). > > But I'd prefer to return 'undefined' instead of 'false' just because that makes > a bit more sense and is less likely to confuse developers (we're not actually > claiming we don't support pointer events).
Description was changed from ========== Added navigator.pointerEnabled that returns false. Also added a counter for its usage. This is a temporary change to collect usage data of (non-standard) navigator.pointerEnabled. Edge still supports the API (desktop only), and some Pointer Event sites rely on it. BUG=631897 ========== to ========== Added navigator.pointerEnabled behind a flag for experiment. Added navigator.pointerEnabled returning undefined behind the PointerEvent flag. Also added a counter for its usage. This is a temporary change to collect usage data of (non-standard) navigator.pointerEnabled. Edge still supports the API (desktop only), and some Pointer Event sites rely on it. BUG=631897 ==========
On 2016/08/22 13:54:01, Rick Byers wrote: > On 2016/08/22 13:53:06, Rick Byers wrote: > > On 2016/08/15 17:11:13, mustaq wrote: > > > On 2016/08/15 14:54:01, dtapuska wrote: > > > > On 2016/08/15 14:49:31, foolip wrote: > > > > > On 2016/08/12 15:09:40, mustaq wrote: > > > > > > On 2016/08/12 11:12:04, foolip wrote: > > > > > > > On 2016/08/12 06:57:42, Yuki wrote: > > > > > > > > On 2016/08/11 22:44:18, dtapuska wrote: > > > > > > > > > I thought there was a way to hide it from the enumeration. My > > ideal > > > > > > scenario > > > > > > > > is > > > > > > > > > to have it return undefined and don't have it in the > enumeration. > > So > > > > we > > > > > > just > > > > > > > > see > > > > > > > > > people querying the value by direct access. > > > > > > > > > > > > > > > > Just drop-by, so I don't understand the details or background. > > > > > > > > Did you mean [NotEnumerable] extended attribute? > > > > > > > > > > > > > > Even that won't quite do the trick, because getOwnPropertyNames will > > > still > > > > > > find > > > > > > > it. > > > > > > > > > > > > > > I am interested to know what reasons you already have for thinking > > that > > > > this > > > > > > > attribute is needed. It could be that the reasons are already strong > > > > enough > > > > > to > > > > > > > just do it, instead of waiting for use counter data and still not > > > finding > > > > > > > anything conclusive. > > > > > > > > > > > > Here is the main motivation, this came up at the PE Hackathon at > > Microsoft > > > > few > > > > > > weeks ago: we want to understand the web compat implications of the > > > proposed > > > > > > Chrome model for PointerEvents (touch capture is implicit, circumvents > > > > > > hit-testing). For that, we would like to find as many sites as > possible > > > > using > > > > > > touch capturing. The PE usage fractions we are seeing are much smaller > > > than > > > > > what > > > > > > Edge does: Chrome for Windows finds ~1% of the page views install a PE > > > > > listener, > > > > > > while Edge finds ~15%. We hypothesized that many sites could be using > > the > > > > > > non-standard navigator.pointerEnabled API (still supported by > Edge)---we > > > > need > > > > > > numbers to support our hypothesis. > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1b8aJOJcGXakstFJslKl87QwvlFHhHwGbQfJwnUTBB... > > > > > > > > > > > > If we are right, we would see numbers much higher than the lowest > > > Navigator > > > > > > attribute count. > > > > > > > > > > > > We can even ignore the part of the count triggered by > > getOwnPropertyNames > > > by > > > > > > deducting the count for NavigatorVendorSub. > > > > > > > > > > > > Seems [NotEnumerable] does the trick for us then, right? Should I go > > ahead > > > > > with > > > > > > it? > > > > > > > > > > Is it > > https://www.chromestatus.com/metrics/feature/timeline/popularity/1347 > > > > > you're looking at, and is the Edge counter for precisely the same thing? > > We > > > > know > > > > > that use counter is broken on fast shutdown and there could be other > > reasons > > > > to > > > > > the discrepancy, but 1% vs. 15% still sounds like a lot. > > > > > > We don't have any insight if the Edge stats came from counters or not. As > Dave > > > mentioned, their navigator.pointerEnabled varies with mobile vs desktop, so > a > > > similar counter won't make much sense on their side. > > > > > > > > > > > > > I did `SELECT page,url FROM > > > > [httparchive:har.2016_06_15_chrome_requests_bodies] > > > > > WHERE body CONTAINS 'pointerEnabled';` in BigQuery and there were 51363 > > > > results. > > > > > I haven't yet figured out how to further analyze results in BigQuery, > but > > > > > looking at the first few pages, I see these things popping up a lot: > > > > > > > > > > > > > > > https://github.com/mattbryson/TouchSwipe-Jquery-Plugin/blob/master/jquery.tou... > > > > > (jquery.themepunch.tools.min.js includes this) > > > > > https://f.vimeocdn.com/p/2.26.5/js/player.js > > > > > https://github.com/nolimits4web/Swiper > > > > > http://www.jssor.com/ > > > > > > > > > > This pattern could explain it: > > > > > > > > > > > > > > > https://github.com/nolimits4web/Swiper/blob/bd6921a556fb92b5ab87601f99bebffcd... > > > > > > > > > > if (window.navigator.pointerEnabled) s.touchEventsDesktop = {start: > > > > > 'pointerdown', move: 'pointermove', end: 'pointerup'}; > > > > > else if (window.navigator.msPointerEnabled) s.touchEventsDesktop = > {start: > > > > > 'MSPointerDown', move: 'MSPointerMove', end: 'MSPointerUp'}; > > > > > > > > > > Taking a closer look at httparchive results might be interesting. If > this > > > > looks > > > > > like the common case, then you may learn what you need in a matter of > > hours > > > > > instead of waiting for 6+ weeks for use counter data. > > > > > > I just ran another httparchive query to rule out MS-prefixed pointerEnabled: > > > ...WHERE REGEXP_MATCH(body, r"[^Mm][^Ss]pointerEnabled") > > > > > > Result: 49,649 hits in 18,738,746 input rows (~0.25%). > > > > > > We agree that this sets an upperbound on the number of sites using > > > pointerEnabled > > > API. But the fraction of pages using the API /that users interact with/ > could > > be > > > totally different: e.g. if many of those 0.25% are really popular, the > > fraction > > > of pages hit would be higher. > > > > > > > > > > > > > I'm getting on a plane now, but I'm a bit worried about adding > > > pointerEnabled > > > > > for measurement purposes. There just isn't a way to measure this without > > > also > > > > > potentially affecting behavior ('pointerEvent' in navigator) so if you > > think > > > > > that adding support for pointerEnabled is at all a good idea, then just > > > having > > > > > it return true and letting it be enumerable from the start might be > safer, > > > > i.e. > > > > > matching exactly what Edge does so you hit all the same code paths. > > > > > > > > Edge changes the way the field reports based on mobile or desktop. > > (depending > > > on > > > > if they have touch events enabled; they found touch events were more > > reliably > > > > written on the web vs pointer events). I think this was rbyers@ idea to > > report > > > > it as undefined. > > > > > > Are you okay if we land returning |false| for now? We will definitely > revisit > > > our > > > decision next week after Rick comes back from vacation. The risks from > > > the behind-the-flag value (whatever it is) is pretty low. > > > > Given that this API is only part of the Pointer Events experiment (and will > > never be shipped to stable) I think the risk is relatively low (certainly much > > lower than the compat risk of just having the PE APIs at all). > > Maybe update the CL title and/or description to make it clear this isn't a > shipping API? Just a temporary experiment behind the PointerEvent > RuntimeEnabledFeature? Done. > > > And yes, we > > really do want dynamic data here - not just httparchive (Microsoft already has > > lots of static data on this property usage from their crawler, they said > they'd > > really like to know what that boils down to in practice in real-world usage). > > > > But I'd prefer to return 'undefined' instead of 'false' just because that > makes > > a bit more sense and is less likely to confuse developers (we're not actually > > claiming we don't support pointer events). Moved back to |undefined|.
On 2016/08/22 17:00:34, mustaq wrote: > On 2016/08/22 13:54:01, Rick Byers wrote: > > On 2016/08/22 13:53:06, Rick Byers wrote: > > > On 2016/08/15 17:11:13, mustaq wrote: > > > > On 2016/08/15 14:54:01, dtapuska wrote: > > > > > On 2016/08/15 14:49:31, foolip wrote: > > > > > > On 2016/08/12 15:09:40, mustaq wrote: > > > > > > > On 2016/08/12 11:12:04, foolip wrote: > > > > > > > > On 2016/08/12 06:57:42, Yuki wrote: > > > > > > > > > On 2016/08/11 22:44:18, dtapuska wrote: > > > > > > > > > > I thought there was a way to hide it from the enumeration. My > > > ideal > > > > > > > scenario > > > > > > > > > is > > > > > > > > > > to have it return undefined and don't have it in the > > enumeration. > > > So > > > > > we > > > > > > > just > > > > > > > > > see > > > > > > > > > > people querying the value by direct access. > > > > > > > > > > > > > > > > > > Just drop-by, so I don't understand the details or background. > > > > > > > > > Did you mean [NotEnumerable] extended attribute? > > > > > > > > > > > > > > > > Even that won't quite do the trick, because getOwnPropertyNames > will > > > > still > > > > > > > find > > > > > > > > it. > > > > > > > > > > > > > > > > I am interested to know what reasons you already have for thinking > > > that > > > > > this > > > > > > > > attribute is needed. It could be that the reasons are already > strong > > > > > enough > > > > > > to > > > > > > > > just do it, instead of waiting for use counter data and still not > > > > finding > > > > > > > > anything conclusive. > > > > > > > > > > > > > > Here is the main motivation, this came up at the PE Hackathon at > > > Microsoft > > > > > few > > > > > > > weeks ago: we want to understand the web compat implications of the > > > > proposed > > > > > > > Chrome model for PointerEvents (touch capture is implicit, > circumvents > > > > > > > hit-testing). For that, we would like to find as many sites as > > possible > > > > > using > > > > > > > touch capturing. The PE usage fractions we are seeing are much > smaller > > > > than > > > > > > what > > > > > > > Edge does: Chrome for Windows finds ~1% of the page views install a > PE > > > > > > listener, > > > > > > > while Edge finds ~15%. We hypothesized that many sites could be > using > > > the > > > > > > > non-standard navigator.pointerEnabled API (still supported by > > Edge)---we > > > > > need > > > > > > > numbers to support our hypothesis. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1b8aJOJcGXakstFJslKl87QwvlFHhHwGbQfJwnUTBB... > > > > > > > > > > > > > > If we are right, we would see numbers much higher than the lowest > > > > Navigator > > > > > > > attribute count. > > > > > > > > > > > > > > We can even ignore the part of the count triggered by > > > getOwnPropertyNames > > > > by > > > > > > > deducting the count for NavigatorVendorSub. > > > > > > > > > > > > > > Seems [NotEnumerable] does the trick for us then, right? Should I go > > > ahead > > > > > > with > > > > > > > it? > > > > > > > > > > > > Is it > > > https://www.chromestatus.com/metrics/feature/timeline/popularity/1347 > > > > > > you're looking at, and is the Edge counter for precisely the same > thing? > > > We > > > > > know > > > > > > that use counter is broken on fast shutdown and there could be other > > > reasons > > > > > to > > > > > > the discrepancy, but 1% vs. 15% still sounds like a lot. > > > > > > > > We don't have any insight if the Edge stats came from counters or not. As > > Dave > > > > mentioned, their navigator.pointerEnabled varies with mobile vs desktop, > so > > a > > > > similar counter won't make much sense on their side. > > > > > > > > > > > > > > > > I did `SELECT page,url FROM > > > > > [httparchive:har.2016_06_15_chrome_requests_bodies] > > > > > > WHERE body CONTAINS 'pointerEnabled';` in BigQuery and there were > 51363 > > > > > results. > > > > > > I haven't yet figured out how to further analyze results in BigQuery, > > but > > > > > > looking at the first few pages, I see these things popping up a lot: > > > > > > > > > > > > > > > > > > > > > https://github.com/mattbryson/TouchSwipe-Jquery-Plugin/blob/master/jquery.tou... > > > > > > (jquery.themepunch.tools.min.js includes this) > > > > > > https://f.vimeocdn.com/p/2.26.5/js/player.js > > > > > > https://github.com/nolimits4web/Swiper > > > > > > http://www.jssor.com/ > > > > > > > > > > > > This pattern could explain it: > > > > > > > > > > > > > > > > > > > > > https://github.com/nolimits4web/Swiper/blob/bd6921a556fb92b5ab87601f99bebffcd... > > > > > > > > > > > > if (window.navigator.pointerEnabled) s.touchEventsDesktop = {start: > > > > > > 'pointerdown', move: 'pointermove', end: 'pointerup'}; > > > > > > else if (window.navigator.msPointerEnabled) s.touchEventsDesktop = > > {start: > > > > > > 'MSPointerDown', move: 'MSPointerMove', end: 'MSPointerUp'}; > > > > > > > > > > > > Taking a closer look at httparchive results might be interesting. If > > this > > > > > looks > > > > > > like the common case, then you may learn what you need in a matter of > > > hours > > > > > > instead of waiting for 6+ weeks for use counter data. > > > > > > > > I just ran another httparchive query to rule out MS-prefixed > pointerEnabled: > > > > ...WHERE REGEXP_MATCH(body, r"[^Mm][^Ss]pointerEnabled") > > > > > > > > Result: 49,649 hits in 18,738,746 input rows (~0.25%). > > > > > > > > We agree that this sets an upperbound on the number of sites using > > > > pointerEnabled > > > > API. But the fraction of pages using the API /that users interact with/ > > could > > > be > > > > totally different: e.g. if many of those 0.25% are really popular, the > > > fraction > > > > of pages hit would be higher. > > > > > > > > > > > > > > > > I'm getting on a plane now, but I'm a bit worried about adding > > > > pointerEnabled > > > > > > for measurement purposes. There just isn't a way to measure this > without > > > > also > > > > > > potentially affecting behavior ('pointerEvent' in navigator) so if you > > > think > > > > > > that adding support for pointerEnabled is at all a good idea, then > just > > > > having > > > > > > it return true and letting it be enumerable from the start might be > > safer, > > > > > i.e. > > > > > > matching exactly what Edge does so you hit all the same code paths. > > > > > > > > > > Edge changes the way the field reports based on mobile or desktop. > > > (depending > > > > on > > > > > if they have touch events enabled; they found touch events were more > > > reliably > > > > > written on the web vs pointer events). I think this was rbyers@ idea to > > > report > > > > > it as undefined. > > > > > > > > Are you okay if we land returning |false| for now? We will definitely > > revisit > > > > our > > > > decision next week after Rick comes back from vacation. The risks from > > > > the behind-the-flag value (whatever it is) is pretty low. > > > > > > Given that this API is only part of the Pointer Events experiment (and will > > > never be shipped to stable) I think the risk is relatively low (certainly > much > > > lower than the compat risk of just having the PE APIs at all). > > > > Maybe update the CL title and/or description to make it clear this isn't a > > shipping API? Just a temporary experiment behind the PointerEvent > > RuntimeEnabledFeature? > > Done. > > > > > > And yes, we > > > really do want dynamic data here - not just httparchive (Microsoft already > has > > > lots of static data on this property usage from their crawler, they said > > they'd > > > really like to know what that boils down to in practice in real-world > usage). > > > > > > But I'd prefer to return 'undefined' instead of 'false' just because that > > makes > > > a bit more sense and is less likely to confuse developers (we're not > actually > > > claiming we don't support pointer events). > > Moved back to |undefined|. Ah, I'm sorry - I hadn't previously read the history of custom bindings here (trying to skim my large backlog after getting back from vacation). I assumed this was possible somehow without custom bindings. Since the bindings team seems to really prefer that we avoid custom bindings, and since dtapuska@ already said to just go with "false", you shouldn't let my preference change your design. For our purposes "false" will be adequate - just add a comment to the impl explaining why we're using that value even though it's really a lie.
On 2016/08/22 17:44:32, Rick Byers wrote: > On 2016/08/22 17:00:34, mustaq wrote: > > On 2016/08/22 13:54:01, Rick Byers wrote: > > > On 2016/08/22 13:53:06, Rick Byers wrote: > > > > On 2016/08/15 17:11:13, mustaq wrote: > > > > > On 2016/08/15 14:54:01, dtapuska wrote: > > > > > > On 2016/08/15 14:49:31, foolip wrote: > > > > > > > On 2016/08/12 15:09:40, mustaq wrote: > > > > > > > > On 2016/08/12 11:12:04, foolip wrote: > > > > > > > > > On 2016/08/12 06:57:42, Yuki wrote: > > > > > > > > > > On 2016/08/11 22:44:18, dtapuska wrote: > > > > > > > > > > > I thought there was a way to hide it from the enumeration. > My > > > > ideal > > > > > > > > scenario > > > > > > > > > > is > > > > > > > > > > > to have it return undefined and don't have it in the > > > enumeration. > > > > So > > > > > > we > > > > > > > > just > > > > > > > > > > see > > > > > > > > > > > people querying the value by direct access. > > > > > > > > > > > > > > > > > > > > Just drop-by, so I don't understand the details or background. > > > > > > > > > > Did you mean [NotEnumerable] extended attribute? > > > > > > > > > > > > > > > > > > Even that won't quite do the trick, because getOwnPropertyNames > > will > > > > > still > > > > > > > > find > > > > > > > > > it. > > > > > > > > > > > > > > > > > > I am interested to know what reasons you already have for > thinking > > > > that > > > > > > this > > > > > > > > > attribute is needed. It could be that the reasons are already > > strong > > > > > > enough > > > > > > > to > > > > > > > > > just do it, instead of waiting for use counter data and still > not > > > > > finding > > > > > > > > > anything conclusive. > > > > > > > > > > > > > > > > Here is the main motivation, this came up at the PE Hackathon at > > > > Microsoft > > > > > > few > > > > > > > > weeks ago: we want to understand the web compat implications of > the > > > > > proposed > > > > > > > > Chrome model for PointerEvents (touch capture is implicit, > > circumvents > > > > > > > > hit-testing). For that, we would like to find as many sites as > > > possible > > > > > > using > > > > > > > > touch capturing. The PE usage fractions we are seeing are much > > smaller > > > > > than > > > > > > > what > > > > > > > > Edge does: Chrome for Windows finds ~1% of the page views install > a > > PE > > > > > > > listener, > > > > > > > > while Edge finds ~15%. We hypothesized that many sites could be > > using > > > > the > > > > > > > > non-standard navigator.pointerEnabled API (still supported by > > > Edge)---we > > > > > > need > > > > > > > > numbers to support our hypothesis. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1b8aJOJcGXakstFJslKl87QwvlFHhHwGbQfJwnUTBB... > > > > > > > > > > > > > > > > If we are right, we would see numbers much higher than the lowest > > > > > Navigator > > > > > > > > attribute count. > > > > > > > > > > > > > > > > We can even ignore the part of the count triggered by > > > > getOwnPropertyNames > > > > > by > > > > > > > > deducting the count for NavigatorVendorSub. > > > > > > > > > > > > > > > > Seems [NotEnumerable] does the trick for us then, right? Should I > go > > > > ahead > > > > > > > with > > > > > > > > it? > > > > > > > > > > > > > > Is it > > > > https://www.chromestatus.com/metrics/feature/timeline/popularity/1347 > > > > > > > you're looking at, and is the Edge counter for precisely the same > > thing? > > > > We > > > > > > know > > > > > > > that use counter is broken on fast shutdown and there could be other > > > > reasons > > > > > > to > > > > > > > the discrepancy, but 1% vs. 15% still sounds like a lot. > > > > > > > > > > We don't have any insight if the Edge stats came from counters or not. > As > > > Dave > > > > > mentioned, their navigator.pointerEnabled varies with mobile vs desktop, > > so > > > a > > > > > similar counter won't make much sense on their side. > > > > > > > > > > > > > > > > > > > I did `SELECT page,url FROM > > > > > > [httparchive:har.2016_06_15_chrome_requests_bodies] > > > > > > > WHERE body CONTAINS 'pointerEnabled';` in BigQuery and there were > > 51363 > > > > > > results. > > > > > > > I haven't yet figured out how to further analyze results in > BigQuery, > > > but > > > > > > > looking at the first few pages, I see these things popping up a lot: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/mattbryson/TouchSwipe-Jquery-Plugin/blob/master/jquery.tou... > > > > > > > (jquery.themepunch.tools.min.js includes this) > > > > > > > https://f.vimeocdn.com/p/2.26.5/js/player.js > > > > > > > https://github.com/nolimits4web/Swiper > > > > > > > http://www.jssor.com/ > > > > > > > > > > > > > > This pattern could explain it: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/nolimits4web/Swiper/blob/bd6921a556fb92b5ab87601f99bebffcd... > > > > > > > > > > > > > > if (window.navigator.pointerEnabled) s.touchEventsDesktop = {start: > > > > > > > 'pointerdown', move: 'pointermove', end: 'pointerup'}; > > > > > > > else if (window.navigator.msPointerEnabled) s.touchEventsDesktop = > > > {start: > > > > > > > 'MSPointerDown', move: 'MSPointerMove', end: 'MSPointerUp'}; > > > > > > > > > > > > > > Taking a closer look at httparchive results might be interesting. If > > > this > > > > > > looks > > > > > > > like the common case, then you may learn what you need in a matter > of > > > > hours > > > > > > > instead of waiting for 6+ weeks for use counter data. > > > > > > > > > > I just ran another httparchive query to rule out MS-prefixed > > pointerEnabled: > > > > > ...WHERE REGEXP_MATCH(body, r"[^Mm][^Ss]pointerEnabled") > > > > > > > > > > Result: 49,649 hits in 18,738,746 input rows (~0.25%). > > > > > > > > > > We agree that this sets an upperbound on the number of sites using > > > > > pointerEnabled > > > > > API. But the fraction of pages using the API /that users interact with/ > > > could > > > > be > > > > > totally different: e.g. if many of those 0.25% are really popular, the > > > > fraction > > > > > of pages hit would be higher. > > > > > > > > > > > > > > > > > > > I'm getting on a plane now, but I'm a bit worried about adding > > > > > pointerEnabled > > > > > > > for measurement purposes. There just isn't a way to measure this > > without > > > > > also > > > > > > > potentially affecting behavior ('pointerEvent' in navigator) so if > you > > > > think > > > > > > > that adding support for pointerEnabled is at all a good idea, then > > just > > > > > having > > > > > > > it return true and letting it be enumerable from the start might be > > > safer, > > > > > > i.e. > > > > > > > matching exactly what Edge does so you hit all the same code paths. > > > > > > > > > > > > Edge changes the way the field reports based on mobile or desktop. > > > > (depending > > > > > on > > > > > > if they have touch events enabled; they found touch events were more > > > > reliably > > > > > > written on the web vs pointer events). I think this was rbyers@ idea > to > > > > report > > > > > > it as undefined. > > > > > > > > > > Are you okay if we land returning |false| for now? We will definitely > > > revisit > > > > > our > > > > > decision next week after Rick comes back from vacation. The risks from > > > > > the behind-the-flag value (whatever it is) is pretty low. > > > > > > > > Given that this API is only part of the Pointer Events experiment (and > will > > > > never be shipped to stable) I think the risk is relatively low (certainly > > much > > > > lower than the compat risk of just having the PE APIs at all). > > > > > > Maybe update the CL title and/or description to make it clear this isn't a > > > shipping API? Just a temporary experiment behind the PointerEvent > > > RuntimeEnabledFeature? > > > > Done. > > > > > > > > > And yes, we > > > > really do want dynamic data here - not just httparchive (Microsoft already > > has > > > > lots of static data on this property usage from their crawler, they said > > > they'd > > > > really like to know what that boils down to in practice in real-world > > usage). > > > > > > > > But I'd prefer to return 'undefined' instead of 'false' just because that > > > makes > > > > a bit more sense and is less likely to confuse developers (we're not > > actually > > > > claiming we don't support pointer events). > > > > Moved back to |undefined|. > > Ah, I'm sorry - I hadn't previously read the history of custom bindings here > (trying to skim my large backlog after getting back from vacation). I assumed > this was possible somehow without custom bindings. Since the bindings team > seems to really prefer that we avoid custom bindings, and since dtapuska@ > already said to just go with "false", you shouldn't let my preference change > your design. For our purposes "false" will be adequate - just add a comment to > the impl explaining why we're using that value even though it's really a lie. Unfortunately a non-hacky way to get |undefined| seems impossible. ptal.
LGTM with nit - 'false' with a warning seems like a great pragmatic tradeoff to me. https://codereview.chromium.org/2217773004/diff/140001/third_party/WebKit/Sou... File third_party/WebKit/Source/core/events/NavigatorEvents.cpp (right): https://codereview.chromium.org/2217773004/diff/140001/third_party/WebKit/Sou... third_party/WebKit/Source/core/events/NavigatorEvents.cpp:51: return false; nit: Here's a simple idea to mitigate the potential confusion of returning "false" instead of "undefined". Generate a console warning when this property is accessed, saying it's a non-standard API and won't ultimately be supported by Chrome. See, for example, Deprecation::countDeprecation for how to generate such a warning.
Description was changed from ========== Added navigator.pointerEnabled behind a flag for experiment. Added navigator.pointerEnabled returning undefined behind the PointerEvent flag. Also added a counter for its usage. This is a temporary change to collect usage data of (non-standard) navigator.pointerEnabled. Edge still supports the API (desktop only), and some Pointer Event sites rely on it. BUG=631897 ========== to ========== Added navigator.pointerEnabled behind a flag for experiment. Added navigator.pointerEnabled returning undefined behind the PointerEvent flag. Also added a counter for its usage. This is a temporary change to collect usage data of (non-standard) navigator.pointerEnabled. Edge still supports the API (desktop only), and some Pointer Event sites rely on it. BUG=631897 TBR=isherman@chromium.org ==========
On 2016/08/22 18:25:52, Rick Byers wrote: > LGTM with nit - 'false' with a warning seems like a great pragmatic tradeoff to > me. > > https://codereview.chromium.org/2217773004/diff/140001/third_party/WebKit/Sou... > File third_party/WebKit/Source/core/events/NavigatorEvents.cpp (right): > > https://codereview.chromium.org/2217773004/diff/140001/third_party/WebKit/Sou... > third_party/WebKit/Source/core/events/NavigatorEvents.cpp:51: return false; > nit: Here's a simple idea to mitigate the potential confusion of returning > "false" instead of "undefined". Generate a console warning when this property > is accessed, saying it's a non-standard API and won't ultimately be supported by > Chrome. See, for example, Deprecation::countDeprecation for how to generate > such a warning. Done.
The CQ bit was checked by mustaq@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from yukishiino@chromium.org, rbyers@chromium.org Link to the patchset: https://codereview.chromium.org/2217773004/#ps160001 (title: "Added a warning.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Still LGTM, thanks!
The CQ bit was unchecked by commit-bot@chromium.org
Failed to apply patch for third_party/WebKit/Source/core/frame/UseCounter.h:
While running git apply --index -3 -p1;
error: patch failed: third_party/WebKit/Source/core/frame/UseCounter.h:1281
Falling back to three-way merge...
Applied patch to 'third_party/WebKit/Source/core/frame/UseCounter.h' with
conflicts.
U third_party/WebKit/Source/core/frame/UseCounter.h
Patch: third_party/WebKit/Source/core/frame/UseCounter.h
Index: third_party/WebKit/Source/core/frame/UseCounter.h
diff --git a/third_party/WebKit/Source/core/frame/UseCounter.h
b/third_party/WebKit/Source/core/frame/UseCounter.h
index
dc466c59ae6d858b1bc350656a0bd27515f92374..87827974933d623955883edf091bfd8e6638c028
100644
--- a/third_party/WebKit/Source/core/frame/UseCounter.h
+++ b/third_party/WebKit/Source/core/frame/UseCounter.h
@@ -1281,6 +1281,7 @@ public:
SVGSMILCurrentTime = 1507,
HTMLBodyElementOnSelectionChangeAttribute = 1508,
ForeignFetchInterception = 1509,
+ NavigatorPointerEnabled = 1510,
// Add new features immediately above this line. Don't change assigned
// numbers of any item, and don't reuse removed slots.
LGTM
The CQ bit was checked by mustaq@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from rbyers@chromium.org, yukishiino@chromium.org, haraken@chromium.org Link to the patchset: https://codereview.chromium.org/2217773004/#ps180001 (title: "Rebased")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Added navigator.pointerEnabled behind a flag for experiment. Added navigator.pointerEnabled returning undefined behind the PointerEvent flag. Also added a counter for its usage. This is a temporary change to collect usage data of (non-standard) navigator.pointerEnabled. Edge still supports the API (desktop only), and some Pointer Event sites rely on it. BUG=631897 TBR=isherman@chromium.org ========== to ========== Added navigator.pointerEnabled behind a flag for experiment. Added navigator.pointerEnabled returning undefined behind the PointerEvent flag. Also added a counter for its usage. This is a temporary change to collect usage data of (non-standard) navigator.pointerEnabled. Edge still supports the API (desktop only), and some Pointer Event sites rely on it. BUG=631897 TBR=isherman@chromium.org ==========
Message was sent while issue was closed.
Committed patchset #10 (id:180001)
Message was sent while issue was closed.
Description was changed from ========== Added navigator.pointerEnabled behind a flag for experiment. Added navigator.pointerEnabled returning undefined behind the PointerEvent flag. Also added a counter for its usage. This is a temporary change to collect usage data of (non-standard) navigator.pointerEnabled. Edge still supports the API (desktop only), and some Pointer Event sites rely on it. BUG=631897 TBR=isherman@chromium.org ========== to ========== Added navigator.pointerEnabled behind a flag for experiment. Added navigator.pointerEnabled returning undefined behind the PointerEvent flag. Also added a counter for its usage. This is a temporary change to collect usage data of (non-standard) navigator.pointerEnabled. Edge still supports the API (desktop only), and some Pointer Event sites rely on it. BUG=631897 TBR=isherman@chromium.org Committed: https://crrev.com/b226b2fff6a3aeeca697ba93d23e579ff873043a Cr-Commit-Position: refs/heads/master@{#413751} ==========
Message was sent while issue was closed.
Patchset 10 (id:??) landed as https://crrev.com/b226b2fff6a3aeeca697ba93d23e579ff873043a Cr-Commit-Position: refs/heads/master@{#413751} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
