Just a meta bug to group all the things related to supporting touch input on desktop platforms once APZ is live. I'm not yet sure of the dependency chain here.
*** Bug 548005 has been marked as a duplicate of this bug. ***
Created attachment 8713677 [details] [diff] [review]
Tests are looking green, https://treeherder.mozilla.org/#/jobs?repo=try&revision=87b78b065d7e&group_state=expanded
I haven't actually tested this patch locally on my Windows touch device, but I can do that this weekend and land the patch after that. I'd prefer to leave this riding the train on 47 so it gets the normal amount of bake time, rather than uplifting it to 46 to go with the rest of APZ.
Comment on attachment 8713677 [details] [diff] [review]
Review of attachment 8713677 [details] [diff] [review]:
Thanks! r+ assuming the testing checks out.
So it turns out that touch scrolling *does* actually work in Windows right now. Without e10s/APZ, you can touch-scroll although it's the windows widget touch gesture goop that is driving it. No touch events are delivered to the web content. Scrolling has inertia. With e10s (with or without APZ), the same is true, except scrolling has no inertia (that's what bug 1187439 is). With e10s and APZ you can additionally turn on dom.w3c_touch_events.enabled=2 and then you get APZ touch scrolling which is the best scrolling of them all.
So I'm going to land this patch, but going to do it #ifdef NIGHTLY for now because it also causes the window.Touch and related stuff to become accessible to web content. That's a fairly large change in that sites might be using that to autodetect mobile vs desktop and there might be some fallout. I also want to get the desktop UX team to tweak the touch physics because it seems a bit sluggish, and in case they don't get around to in 47 I don't want this accidentally riding the trains.
*** Bug 1285335 has been marked as a duplicate of this bug. ***