Chrome Version       : 52.0.2739.0

What steps will reproduce the problem?
1. Start Chrome without touch events enabled (no touchscreen attached, chrome://flags/#touch-events set to it's default or 'Disable).
1. Load a simple page that has touch event listeners, eg. http://output.jsbin.com/hepomuc/?quiet=1
2. Open devtools in mobile emulation mode
3. Enable scrolling performance issues
4. Reload the page a few times

What is the expected result?
Expect to see a "touch event listener" rectangle consistently covering the page

What happens instead of that?
Occasionally I see no touch rect, and then clicking (sending a synthetic touch) either doesn't trigger the handler at all, or sends a touch event with cancelable=false (indicating the compositor does not believe there to be a blocking touch handler at that point).

This has been frustratingly difficult to reproduce, but what I suspect is happening is this:

1. Whenever there is a compositing change ScrollingCoordinator::updateTouchEventTargetRectsIfNeeded runs
 - It bails out if RuntimeEnabledFeatures::touchEnabled isn't set
2. DevTools sets RuntimeEnabledFeatures::touchEnabled when mobile emulation is started

If the page loads/draws quickly enough, #1 may occur before #2.  In that case there won't be any touch rects registered and touch events will not work properly. If the page under test does anything to trigger a compositing update everything will be fine (but for simple test pages this can be quite long lasting and so result in very confusing behavior).

I think we just need some way for devtools to force a compositing update after it enables the RuntimeEnabledFeature.

I often run with --touch-events=enabled which is why I think I haven't noticed this before.