InputDeviceCapabilities is Chrome-only |
|||
Issue descriptionIt's been two years since we first enabled the UIEvent.sourceCapabilities API ( issue 476530 ), and Chrome is still the only browser to ship it. Usage is at ~0.04% of page views (low but non-trivial): https://www.chromestatus.com/metrics/feature/timeline/popularity/1098 Searching GitHub I do find some projects using it legitimately: https://github.com/search?l=JavaScript&q=sourceCapabilities&type=Code&utf8=%E2%9C%93 We should consider if there's anything we could do to support adoption by other browsers, eg: - File bugs on the other browsers to track considering adding support - Add support for more of the use cases people felt were interesting - Once we have the automation support, write automated web-platform-tests - Of the hits in HTTP Archive, see if we can demonstrate better behavior on any sites in Chrome This API is really only useful on browsers which support TouchEvents on desktop (i.e. not Safari). I think Edge may have recently moved to a model where touch events are enabled on desktop if a touchscreen is attached, but perhaps this isn't in the main builds yet? Of course it's possible that I was just wrong about the value of this API and we should remove it. Of course _I_ don't think that's the case ;-)
,
Sep 25 2017
Agreed that (issue 645116) probably has more cross-browser impact. Perhaps we should poke the Edge team on that - see if they're planning on supporting it?
,
Sep 28 2017
I'll do the follow up and update the issue.
,
Oct 13 2017
Just remembered this discussion (about touch-action for pen vs touch), which suggests that .pointerMovementScrolls is not very useful: https://github.com/w3c/pointerevents/issues/203#issuecomment-299573524 I kind of agree with it after looking at the big picture. So we shouldn't really invest in pointerMovementScrolls unless we fix this issue. Looking into HTTP Archive as Rick suggested above seems to be the right first step to me.
,
Nov 24 2017
HTTP Archive data suggests that ~0.02% pages use this features. [Detailed results] out of 16343951 pages in table har.2017_10_15_chrome_requests_bodies, we have: - "sourceCapabilities" in 3454 pages, - "firesTouchEvents" in 3445 pages, and - "sourceCapabilities.firesTouchEvents" in 3305 pages. However, chromestatus shows that page views for the feature has double to above 0.10+% in the past month: https://www.chromestatus.com/metrics/feature/timeline/popularity/1098
,
Nov 24 2017
Tried to see if there is a common library includes in the above pages that could be causing the recent spike in usage. Here is the js names with frequency of occurrences (in a sample of 50 sites containing "sourceCapabilities"):
22 this.js
26 b.js
27 min.js
35 s.js
40 virtualpage-canal-mobile-component.js
47 e.js
63 t.js
84 component.js
Web/github search didn't point to any of them for "sourceCapabiilties".
,
Dec 5 2017
Correcting my analysis on the last (deleted) post: - Out of the 3.4k pages in HTTP Archive with 'sourceCapabilities', ~25% (~850) use hammer.js or hammer.min.js. No other js ref really stand out. - The recent increase in chromestatus caused by changes in metrics. Apparently the new usage number (0.1% ) is more accurate. The fact that ~0.02% of the pages getting ~0.1% usage suggests that some popular sites may be dominating the usage. Navid, can we use UKM data to find them? |
|||
►
Sign in to add a comment |
|||
Comment 1 by mustaq@chromium.org
, Sep 25 2017