smile.wjp@ : Thanks for the report, From the given link found "Browser Sample" extension and added to Chrome.Could you please help how to proceed further from Test Engg side to further triage it.

durga.behera@ :
thank you for your reply.

"Browser Sample" App contained 2 html files.
- browser.html
- webview1.html

i'm using webview tag in browser.html
and added touch and mouse event handler browser.html body(browser.js 99~108 lines, https://github.com/smilejp/electron-webview-event-test/blob/master/chrome_app_test_based_official_sample/browser.js#L99) and webview1.html body(webview.js 3~12 lines, https://github.com/smilejp/electron-webview-event-test/blob/master/chrome_app_test_based_official_sample/webview.js#L3)

execute "Browser Sample" App, can found white, light green, red area.

light green and red area is webview's area.
white area is browser.html body area.

if you touch red area, handle touch event only webview.
if you click red area, handle mouse event both webview and browser's body

Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

I have another example of what appears to be a related issue, which is here https://github.com/IamfromSpace/webview-touch-bug

In summary, touchstart events from within a webview cause strange behaviors when other webviews or the main window is tapped.

More details (also in the example README):

In touch emulation mode (in chrome 52 and below, fixed in 55):
-no mouse events occur in webviews
-With a Planar Touch screen on Windows 7 and Windows 10:

mouse events correctly occur in the webview under normal circumstances
-If an element is tapped that calls e.preventDefault() on touchstart:
--Mouse events will NOT occur on the next click in a different context (webview, or main frame)
--These effects "stack." Tapping the element four times will mean that four taps do not fire mouse clicks when switching contexts.

As an example:
-You must be using Windows (or linux?) with an actual touchscreen--not emulation

-Tap back and forth between the main and webview click counters they will increment exactly once for each tap

-Tap the Prevent touchstart default: button
--it will increment once

-Tap the main click counter button twice.
--The first touch is ignored, and the second increments the counter
--it should increment twice

-Tap the webview click counter button twice.
--The first touch is ignored, and the second increments the counter
--it should increment twice

-Tap the Prevent touchstart default: multiple times
--it will increment once per tap

-Tap the main click counter button one more times than the value shown on the Prevent touchstart default: button
--Only the last touch will create a click event and the rest will not
--it should increment once per tap

We're seeing the same issue reproduced inside the Windows Surface Pro series of devices. Because this is so reproducible, we're also seeing the same behavior with touch events inside the Electron framework (which includes a build of Chromium inside it).

Any update on when this will get in the queue would be greatly appreciated.

^ Whatever he said.

Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919

Any update on this issue would be gratefully received 

I am seeing a similar error in my chrome app on both Chrome OS  58 (Chromebook) and windows. Is there an update on this issue?

I have a patch prepared for the issue I reported, however on additional investigation, I'm not convinced that the original issue is the same.  As such, I've opened a new issue here:  https://bugs.chromium.org/p/chromium/issues/detail?id=736623

Is this bug fixed until now? I test in Chrome/61.0.3163.100, but it's still here. Anyone knows? Thanks very much~

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.