Hi Juan,

Can you take a look and confirm if this a regression as the partner is reporting that a prior release (m48?) did not have this issue.

Confirmed that this is a regression.

App using "document.addEventListener("touchmove", idleTimer, false);" is working fine on: 
	
Sumo
48.0.2564.116 

but not working on:

Sumo
49.0.2623.95

Juan is OOO. Is regression per #4. Assigning for fix.

Assigning to rbyers to triage in upper layers

This is a Chrome App using <webview> tag, right?  Then wjmaclean is the expert.

I guess we disconnected this in https://codereview.chromium.org/1412923009/ when we started routing touch events for WebViews directly to the guest renderer, bypassing the embedder.

I guess we need to think about a suitable pathway to take touches that are unconsumed by the guest and make them available to the embedder ...

Adding tdresser@ as we'll need his input as to how best to accomplish this.

Would enabling this be safe from a security perspective?

Are we planning to enable the parent document to see touch events targeted at OOPIFs?

For webviews, there is no security problem with the embedder listening for events that target the guest, because chrome apps are trusted more than web content.

This would be a security problem on the open web, though, which is why out-of-process iframes do not have this property and need to have input routed directly from the browser process. This bug is a consequence of the ongoing work to bring the two architectures together.

I was really hoping to get rid of the input event forwarding code from embedder to guest but it isn't clear how to solve this problem if we do that.

James, can we share the event reposting logic with gestures?

Re #16: yes, and we could even potentially do something better than re-posting (e.g. never targeting the guest if it doesn't have a touch handler, or re-targeting the event if the ack from the guest indicates the event was unconsumed).

However, that the touch events ever went to the embedder in the first place may have been unintended. I'm curious to know what the use case is for wanting the embedder to process the touch events that nominally belong to the guest? Does the guest have a touch handler in this use-case? (If it does, it seems odd that we would have multiple handlers firing for a single event.)

From a web developer's perspective, it would be ideal if webviews didn't have any impact on event dispatch.

https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-basic

i.e., capturing listeners in the embedder should see the event before the webview gets a crack at it.

For some additional context, capturing listeners on embedded plugins (via <object> tag) *do* fire for input events targeting them, but that is not true on Firefox, and there is a bug assigned to me arguing that we should match their behavior. Obviously iframe embedders do not see events targeted to the iframes. The latter is compliant to spec because capture and bubble do not pass through nested browsing contexts.

Both of the above are important for security reasons, which is not true for <webview>. Still, since it is a separate browsing context I would argue that we shouldn't capture/bubble across the boundary, except that it differs from how events worked before and there is a lot of value in simply not changing behavior of features that developers are using.

The flash content in the webview will receive a wrong touch position because of this bug.
As the attached picture shown, the webview start from (i, j), and if we touch the blue point (x, y), the purple point (x+i, y+j) will actually be clicked.
This can be reproduced in this app https://github.com/KochiyaOcean/chrome-webview-bug

Deleted: 1.png 9.5 KB

	1.png 9.5 KB View Download

Re #21 I don't think this bug is the cause of the coordinates for the events being wrong in the webview; wyf7789@, could you please create a separate bug for that, and include your sample app and screenshot? Thanks.

Given the desire to use the same codepath for webview and oopif, and given that it's possible to inject script into a webview to allow it to share events with its embedder, I'm going to mark this as wontfix.