Issue metadata
Sign in to add a comment
|
All touch events stop working when a page in an iframe reloads
Reported by
parrott....@gmail.com,
Oct 13 2017
|
||||||||||||||||||||||
Issue description
Steps to reproduce the problem:
1. On an Android device using Chrome (any channel currently), open the attached touchkiller's sample.html page with remote debugging on (to see the console)
2. To make it happen quickly, keep tapping the page.
3. You should see a message "It's still working!" in the console and at one point, after 1 or 2 page reloads occur, the message will stop showing.
4. At this point, all touchstart, touchmove, and touchend events don't occur anymore in the iframe and outside as well.
What is the expected behavior?
What went wrong?
When a page inside an iframe uses addEventListener('touchstart', xxx, false) (on any element including document), something 'seems' to be triggering an issue where after the touchstart event fires at least once, there is a chance on a page reload or move to a different page that in that next page all touch events don't work.
The sample attached simply attaches an event listener that outputs to the console on touchstart.
That page is inside an iframe (required).
There is a timer that reloads the page inside the iframe every second.
If you just keep touching, especially really quickly, on the first reload touch events will already stop working.
Did this work before? Yes 58.x (tested), date-wise, probably 60.x
Does this work in other browsers? Yes
Chrome version: 61.0.3163.98 Channel: stable
OS Version: 8.0
Flash Version:
This a major issue that is currently effecting most social online web games in Japan as they are built so users touch the page rapidly to skip sections of animations. Currently multiple games from multiple companies are having customers complain about not being able to navigate forward (because the touch events that handle that forwarding have stopped working).
,
Oct 13 2017
Navid, bisected locally to your change. This is a pretty important bug to investigate. You are probably looking for a change made after 481654 (known good), but no later than 481655 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/db57d232f21b4f2b09c362d6fabeb2a2286cd863..8af61ebffa92e8d012cb0a9046bcf91aa7762ece
,
Oct 13 2017
Dave, can you elaborate on the steps to reproduce with the devtools. I kept clicking while devtools was on touch emulation and kept getting the still working message.
,
Oct 13 2017
Add a touchmove listener to badguy.html as well. Constantly move the touch point. (press the mouse button in emulation and keep moving) after a Reload of the iframe release the mouse button. Later touchstarts or moves won't get dispatched.
,
Oct 13 2017
Aha. Just a note here. It was working fine with touch emulation on Mac. But it does fail as you said with touch emulation on Linux. I'll dig into this.
,
Oct 16 2017
amineer@ we have a fix for this issue but I'm not 100% that it wouldn't cause any regression. What is your opinion about this issue? Is this something we need to merge the fix in 62 considering the impact or can we skip 62 and go for 63?
,
Oct 16 2017
Sorry to butt in but I would very much like to see this fixed by 62 or even as a patch to 61. In Japan this bug wipes out entire social gaming ecosystems (sites where games are played on platforms and each vendor provides their games through an iframe, number of users enter the millions). Even more so since Android's system WebView uses the locally installed Chrome from Play Store to render content and that makes it look like the developer's applications themselves are bugged and not Chrome. Customer support is very tough.
,
Oct 16 2017
This regressed in M61, right? Any idea why we're only hearing about it now? There's not a bunch of other dupe bugs elsewhere, is there? I believe M62 is basically done so it would have to be a major emergency in order to get anything into it at this point. Marking blocking for 63, but we can upgrade that to 62 if there's a strong enough argument for it.
,
Oct 16 2017
+cmasso@ as the M62 Android owner; also adding to WebView component given c#7.
,
Oct 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fdbb2450a2b131d8e08c48e9b411d7cb94ce2cba commit fdbb2450a2b131d8e08c48e9b411d7cb94ce2cba Author: Navid Zolghadr <nzolghadr@chromium.org> Date: Fri Oct 20 17:47:48 2017 Clear touchpoint map if receiving doc is destroyed When the receiving document of the touch events is destroyed we need to still update the new touch points so they get cleared when they release or they get canceled. Bug: 774446 Change-Id: I8903cd77464eeeeb2f659be13754ced6af8064bf Reviewed-on: https://chromium-review.googlesource.com/719340 Commit-Queue: Navid Zolghadr <nzolghadr@chromium.org> Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Cr-Commit-Position: refs/heads/master@{#510481} [modify] https://crrev.com/fdbb2450a2b131d8e08c48e9b411d7cb94ce2cba/third_party/WebKit/Source/core/BUILD.gn [modify] https://crrev.com/fdbb2450a2b131d8e08c48e9b411d7cb94ce2cba/third_party/WebKit/Source/core/input/TouchEventManager.cpp [add] https://crrev.com/fdbb2450a2b131d8e08c48e9b411d7cb94ce2cba/third_party/WebKit/Source/core/input/TouchEventManagerTest.cpp
,
Oct 23 2017
,
Oct 24 2017
Has this fix been verified in Canary?
,
Oct 24 2017
As far as I tested on 64.0.3247.0 it worked. Do you want one of the QA testers to also verify it?
,
Oct 24 2017
Your change meets the bar and is auto-approved for M63. Please go ahead and merge the CL to branch 3239 manually. Please contact milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/216cfd84c9dcb5a58f6090b6654c6a23c4d2590c commit 216cfd84c9dcb5a58f6090b6654c6a23c4d2590c Author: Navid Zolghadr <nzolghadr@chromium.org> Date: Wed Oct 25 14:52:53 2017 Clear touchpoint map if receiving doc is destroyed When the receiving document of the touch events is destroyed we need to still update the new touch points so they get cleared when they release or they get canceled. Bug: 774446 Change-Id: I8903cd77464eeeeb2f659be13754ced6af8064bf Reviewed-on: https://chromium-review.googlesource.com/719340 Commit-Queue: Navid Zolghadr <nzolghadr@chromium.org> Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#510481}(cherry picked from commit fdbb2450a2b131d8e08c48e9b411d7cb94ce2cba) Reviewed-on: https://chromium-review.googlesource.com/738329 Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org> Cr-Commit-Position: refs/branch-heads/3239@{#214} Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578} [modify] https://crrev.com/216cfd84c9dcb5a58f6090b6654c6a23c4d2590c/third_party/WebKit/Source/core/BUILD.gn [modify] https://crrev.com/216cfd84c9dcb5a58f6090b6654c6a23c4d2590c/third_party/WebKit/Source/core/input/TouchEventManager.cpp [add] https://crrev.com/216cfd84c9dcb5a58f6090b6654c6a23c4d2590c/third_party/WebKit/Source/core/input/TouchEventManagerTest.cpp
,
Oct 25 2017
The fix is also merged into 63. parrott...@ Could you also please verify with your use cases on the latest Canary and the next M63 beta that should come out by tomorrow?
,
Oct 26 2017
Verified using ES File Explorer(4.1.6.9.2 ) on Nexus 5X(OPR1.170623.011) ,putting the touchkiller badguy files and opening them on HTML viewer ,scroll issue was not reproducible anymore in Monochrome Beta 63.0.3239.20 . Issue was reproducible in 61.0.3163.98 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Oct 13 2017Labels: -Pri-2 Pri-1
Owner: nzolghadr@chromium.org
Status: Assigned (was: Unconfirmed)