Note that when making this change we should spot-check a few sites and verify we don't appear to be breaking anything on mobile.  Eg. if the touch code has only ever been hit on Safari before, it's possible it could cause more problems than it fixes by suddenly being enabled on Chrome (eg. maybe there are assumptions based on the user agent string).  I don't expect any major issues, just worth checking.

Here's a list of all the httparchive search results: https://docs.google.com/spreadsheets/d/1EUyotOsyCMKYPavWKFF5vcOOqLeoDzIcqlscCMrzBWY/edit?usp=sharing

Changing the initTouchEvent(...) will certainly cause issues;

See the YUI library that has UA checks for android.

https://github.com/yui/yui3/blob/master/src/event-simulate/js/event-simulate.js

We should try to implement the initTouchEvent as described on: https://developer.apple.com/library/iad/documentation/UserExperience/Reference/TouchEventClassReference/index.html#//apple_ref/javascript/instm/TouchEvent/initTouchEvent

in addition to our current implementation.

Yikes, UA checks like that are exactly the thing we're trying to make unnecessary.  Yes if we can support the Safari behavior while also still supporting our existing behavior (to the extend necessary for web compat) that's probably ideal.  We'll have to decide whether we should spec the Safari behavior, or the new weird Safari+Chrome behavior - probably by asking Edge and Mozilla folks what they prefer (I'm guessing the latter - even though it's ugly).

Waiting for Apple's response

Let's not wait any longer for a response, just do our best to match Safari's behavior (given some basic testing)...

I just re-read what I wrote in the W3C bug: https://github.com/w3c/touch-events/issues/29:

Do we have any idea yet why the httparchive data and Chrome UMA data seem so inconsistent?  In particular, if you try loading some of the matching sites from httparchive, do they trigger the Chrome use counter before (or after) your fix?  Eg. if we do the type-checking and whatnot first then Safari-style uses of the API wouldn't trigger our use counter and that could explain the anomaly.

You can check to see if the Chrome use counter is triggered by going to chrome://histograms/WebCore.FeatureObserver and looking at the count for bucket #872 (V8TouchEvent_InitTouchEvent_Method).

FWIW, I'm open to being convinced that this is not worth doing (given that we have the constructors as the right interoperable solution for the future).  But since our goal was always to match Safari and there are apparently a largish number of sites using this from Safari, it's worth some effort to try to reconcile IMHO.

It seems that the major libs (html5player.js, ima3.js, YUI.js) only provide a function to simulate touch events, but websites never use that.

And other libs (rokbox.js(specific version), mootools-mobile.js, powertools-1.2.0.js) will do the iOSTouch check but actually it will return false on both Chrome and Safari. e.g.

'''
var e = document.createEvent("TouchEvent"); // Exception on non-touch devices
e.initTouchEvent('cantouch'); // Safari requires all params, so TypeError
'''


To trigger initTouchEvent use count:
1. Open http://www.kaeufersiegel.de/ on mobile (non-touchscreen desktop won't work)
2. Click any link or do a refresh
3. chrome://histograms/WebCore.FeatureObserver bucket #872 will increase, triggered by http://www.kaeufersiegel.de/modules/mod_djimageslider/assets/powertools-1.2.0.js


After my fix I don't think it will change anything, YUI get data from UA and will continue working, other libs with iOSTouch detection will still return false for Safari and Chrome.

Fascinating, thanks for the details.  So we don't have any specific sites
that behave better with this fix.  This explains why it's not as big of a
problem as I feared, thanks.  Still seems worth doing to me unless anyone
wants to argue otherwise.

I've tested the Browser.Features.iOSTouch given in the description, by changing document.html to document.documentElement. It's false in Mobile Safari as well, because  it throws a TypeError on e.initTouchEvent(a).

There's something strange going on here, because WebKit's IDL doesn't match Safari's behavior. Let's discuss in the review.

After further discussion and looking at more of the data, the decision now is to deprecate and remove initTouchEvent.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0a4b585a8dcf0a4311b5a06023b43c337c321404

commit 0a4b585a8dcf0a4311b5a06023b43c337c321404
Author: chongz <chongz@chromium.org>
Date: Mon Dec 21 23:04:17 2015

Deprecate initTouchEvent

Document.initTouchEvent is not standardized and not interoperate with
Firefox or Safari. Developers should be encouraged to use new TouchEvent
constructor instead.

To be removed in M53

BUG= 522100 

Intent to Deprecate and Remove:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/dqlJguVuIHs

Related:
http://crrev.com/1410833006

Review URL: https://codereview.chromium.org/1536733002

Cr-Commit-Position: refs/heads/master@{#366484}

[modify] http://crrev.com/0a4b585a8dcf0a4311b5a06023b43c337c321404/third_party/WebKit/LayoutTests/fast/events/touch/document-create-touch-list-expected.txt
[modify] http://crrev.com/0a4b585a8dcf0a4311b5a06023b43c337c321404/third_party/WebKit/LayoutTests/fast/events/touch/touch-event-dispatch-no-crash-expected.txt
[modify] http://crrev.com/0a4b585a8dcf0a4311b5a06023b43c337c321404/third_party/WebKit/Source/core/events/TouchEvent.idl
[modify] http://crrev.com/0a4b585a8dcf0a4311b5a06023b43c337c321404/third_party/WebKit/Source/core/frame/UseCounter.cpp

Note that the deprecation warning says we're going to remove this in M53 but M53 has branched now.  Should we update the warning to say M54 (merge that) then remove it on trunk?

Rick,

It looks like I missed a step here. Which version of Chrome was it
deprecated in? FYI, we don't have a status entry for this.

Joe

Joe Medley | Technical Writer, Chrome DevRel | jmedley@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*

Looks to me it was deprecated in 49.

jmedley@,

Apologize if I did the deprecated steps wrong or missed something...

It was deprecated in M49 and here is the status entry:
https://www.chromestatus.com/features/5730982598541312

Thanks!

No need to apologize. An hour ago I would have sworn it wasn't on Chrome
Status. Weird.

Joe Medley | Technical Writer, Chrome DevRel | jmedley@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/44cc3124a56262d937b36a3d6d0d3de626082716

commit 44cc3124a56262d937b36a3d6d0d3de626082716
Author: chongz <chongz@chromium.org>
Date: Fri Jul 29 05:30:39 2016

Remove |TouchEvent.initTouchEvent()| in M54

|TouchEvent.initTouchEvent()| is not standardized and not interoperate
with Firefox or Safari. Developers should be encouraged to use the new
TouchEvent constructor instead.

|initTouchEvent()| was deprecated in M49, and this CL removes it
in M54 (deferred from M53).

Intent to Deprecate and Remove:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/dqlJguVuIHs

Chrome Status Entry:
https://www.chromestatus.com/features/5730982598541312

TBR=timvolodine
BUG= 522100 

Review-Url: https://codereview.chromium.org/2182183003
Cr-Commit-Position: refs/heads/master@{#408579}

[modify] https://crrev.com/44cc3124a56262d937b36a3d6d0d3de626082716/android_webview/tools/system_webview_shell/test/data/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/44cc3124a56262d937b36a3d6d0d3de626082716/third_party/WebKit/LayoutTests/fast/events/touch/document-create-touch-list-expected.txt
[modify] https://crrev.com/44cc3124a56262d937b36a3d6d0d3de626082716/third_party/WebKit/LayoutTests/fast/events/touch/script-tests/document-create-touch-list.js
[modify] https://crrev.com/44cc3124a56262d937b36a3d6d0d3de626082716/third_party/WebKit/LayoutTests/fast/events/touch/touch-event-dispatch-no-crash-expected.txt
[modify] https://crrev.com/44cc3124a56262d937b36a3d6d0d3de626082716/third_party/WebKit/LayoutTests/fast/events/touch/touch-event-dispatch-no-crash.html
[modify] https://crrev.com/44cc3124a56262d937b36a3d6d0d3de626082716/third_party/WebKit/LayoutTests/virtual/stable/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/44cc3124a56262d937b36a3d6d0d3de626082716/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/44cc3124a56262d937b36a3d6d0d3de626082716/third_party/WebKit/Source/core/events/TouchEvent.cpp
[modify] https://crrev.com/44cc3124a56262d937b36a3d6d0d3de626082716/third_party/WebKit/Source/core/events/TouchEvent.h
[modify] https://crrev.com/44cc3124a56262d937b36a3d6d0d3de626082716/third_party/WebKit/Source/core/events/TouchEvent.idl

initTouchEvent removed in M54.

Could you please also clean up the removal warning (in Deprecation.cpp)?

Back to chongz@ to remove the deprecation warning.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/843b0c5cf6cbcb96d5e1314e37f041e7d2da1959

commit 843b0c5cf6cbcb96d5e1314e37f041e7d2da1959
Author: chongz <chongz@chromium.org>
Date: Wed Aug 24 01:05:56 2016

Cleanup |initTouchEvent| deprecation warning and usecounter

|TouchEvent.initTouchEvent()| was removed in M54, so we no
longer need these deprecation warning and usercounter.

See https://chromium.googlesource.com/chromium/src.git/+/44cc3124a56262d937b36a3d6d0d3de626082716

BUG= 522100 

Review-Url: https://codereview.chromium.org/2276523002
Cr-Commit-Position: refs/heads/master@{#413919}

[modify] https://crrev.com/843b0c5cf6cbcb96d5e1314e37f041e7d2da1959/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/843b0c5cf6cbcb96d5e1314e37f041e7d2da1959/third_party/WebKit/Source/core/frame/UseCounter.h