In bug 96295, I added window.Touch and window.TouchList constructors when built with TOUCH_EVENTS. At least one web app uses the existance of window.Touch to infer that they're on a mobile default (and so shouldn't listen to mouse events). This is completely broken and we need to get such sites fixed, but our strategy should be the same as for more common (but equally wrong) check sites do like looking for window.ontouchstart (which, for now, we enable dynamically at runtime - eg. based on whether or not a touch screen is actually present)
For now (Chrome M25) I'm going to revert my change. I'll file a separate bug to put these back but controlled dynamically.
Created attachment 181258 [details]
Will track re-landing this in the original bug: bug 96295
Comment on attachment 181258 [details]
Clearing flags on attachment: 181258
Committed r138808: <http://trac.webkit.org/changeset/138808>
All reviewed patches have been landed. Closing bug.