Can we reproduce in Safari or Firefox?

Assigning to Eugene as FYI.
I think this is similar to what a testflight tester was reporting. 

I tried to repro this on Dev and could not repro. I also tried on Firefox and could not repro - at most I saw delayed or slow rebounding, but that happened in Firefox and well as Chrome. We can check into it more on the test team though on some different devices/configs and see.

I am able to reproduce on latest M59 canary.
Repro steps:
Goto iOS Device Settings -> General -> Accessibility -> Speech -> Speak Selection --> Turn ON
Launch Chrome
Open any article from nytimes.com (Or the same webpage from the original bug report)
Scroll down to go into Fullscreen mode
Select any text (selecting a single line/para will do)
Try to scroll the page up/down few times

Chrome Freezes.
Works fine in Safari and Firefox.

Doesn't repro when you Turn OFF Speak Selection from a11y.

Video from my repro steps:
https://drive.google.com/file/d/0B-xmXLQhjeKuSkFxZUhVd2RfRjg/view

I am able to reproduce with steps in #5, however I had to use an old tab. When I went back to, it triggered a reload, and then I could reproduce, I was unable to reproduce in a new tab.

Thanks for the updated steps, I will investigate.

Just went over the repro steps posted by Srikanth in Comment #5 - as opposed to what was discussed in office hours, comment #5 should _not_ be separated into a separate bug because in these videos linked from comment #0 Jason T has turned on the Speak Selection option - you can see the Speak option showing in the long press options in the videos. 

So the repro steps in comment #5 are representative of the issues from the videos in comment #0. 

Please let me know if there are any other questions.

I've been debugging this and I don't know the cause yet, but here is what I do know:

- Not reproducible in WKWebView sample app.
- Entire app is not frozen, tapping on status bar will reveal top bar (if hidden) and tab can be closed, then app works normally. However, WKWebView content is completely frozen.
- Even when WebView is frozen, touches are received in touchesBegan:withEvent: in both crw_touch_tracking_recognizer.mm and side_swipe_gesture_recognizer.mm.

This issue does not seem to be caused by
- javascript injection
- side swipe gesture recognizer

I finally tracked down a source of the issue. If I comment out setTopContentPadding: in ios/web/web_state/ui/crw_web_view_content_view.mm the issue is no longer reproducible.

I take back comment #11, it seems harder to reproduce, but I can indeed still reproduce it without the contents of that method.

(Now) I've finally tracked down the source of the issue. In ios/chrome/browser/ui/overscroll_actions/overscroll_actions_controller.mm, setWebViewInteractionEnabled: is called many times, the last time being with enabled = NO. This causes the webView to become unresponsive to any touch.

I'm not sure of the cause, adding jif@ as owner of overscroll_actions directory for any insight.

I'm marking this as RBS for M58. 

Great investigation michaeldo@, this must not have been easy to find.
Looking at what changed in overscroll_actions_controller.mm.

It was indeed not easy to find. :)

Thanks for taking a look, updating owner and status. 

Like michaeldo says, setWebViewInteractionEnabled:YES is sometimes not called.
That's because a UIPanGestureRecognizer sometimes does not send a UIGestureRecognizerStateEnded action to its targets.

However, if I KVO the gestureRecognizer's |state| property, it always correctly changes to UIGestureRecognizerStateEnded.

One last bit of info: the bug has been present since (at least) M54.

Thanks jif@. It is very important to know that this is not a regression.

Note: iOS 10.x only. Cannot repro on iOS 9.3.

jif@ what is the latest update

Radar filed: radar://31449848
Workaround (not yet landed): https://codereview.chromium.org/2787723003

What's the update on the workaround. The CL got lgtmed but never landed. Could you address Justin's questions and land it? We need to make sure this workaround does not break anything.

+ noyau: Could someone take a look at this RBS and drive it to closure while jif@ is out this week ?

I copied the CL to here with minor changes: https://codereview.chromium.org/2817483002/ Will wait for rohitrao@ and noyau@ before landing.

Any update? Can we land this CL?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/998bf426e310eda213fa80898a840a89f815d676

commit 998bf426e310eda213fa80898a840a89f815d676
Author: justincohen <justincohen@chromium.org>
Date: Thu Apr 13 03:03:57 2017

[Workaround] Notify Overscroll Actions that a gesture ended.

The OverscrollActionController adds a UIPanGestureRecognizer.
When text is selected and SelectionSpeak is enabled, the
UIPanGestureRecognizer's end state is not always communicated to the
OverscrollActionController.

This CL calls the OverscrollActionController whenever the
UIPanGestureRecognizer is reset.

patchset from jif@chromium.org

TEST=Enable SelectionSpeak. Visit a page. Select text. In a single gesture, scroll a
little bit up and down. Once you lift your finger from the screen, the browser
should not be frozen, i.e. you should be able to scroll the page.
BUG= 699655 

patch from issue 2787723003 at patchset 40001 (http://crrev.com/2787723003#ps40001)

Review-Url: https://codereview.chromium.org/2817483002
Cr-Commit-Position: refs/heads/master@{#464267}

[modify] https://crrev.com/998bf426e310eda213fa80898a840a89f815d676/ios/chrome/browser/ui/overscroll_actions/BUILD.gn
[modify] https://crrev.com/998bf426e310eda213fa80898a840a89f815d676/ios/chrome/browser/ui/overscroll_actions/overscroll_actions_controller.mm
[add] https://crrev.com/998bf426e310eda213fa80898a840a89f815d676/ios/chrome/browser/ui/overscroll_actions/overscroll_actions_gesture_recognizer.h
[add] https://crrev.com/998bf426e310eda213fa80898a840a89f815d676/ios/chrome/browser/ui/overscroll_actions/overscroll_actions_gesture_recognizer.mm

cmasso@ I do not think this CL is safe enough to be cherry picked back to M58.  I'd prefer it stay on trunk and bake a little.

Can this be considered for a respin?

[Auto-generated comment by a script] We noticed that this issue is targeted for M-58; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-58 label, otherwise remove Merge-TBD label. Thanks.

Tested on M58.0.3029.83 in iPhone7(iOS 10.2.1). 

Followed the steps mentioned in comment#5. On select of the text and scroll a bit of up and down will not freeze the application.

Reopening because the fix never made it to M58, right?  We should double-check current M58 builds and take another look at the listed repro steps.

(I believe this bug is fixed on trunk and M59, but not on M58.)  We should verify the fix on those builds.

I thought we have agreed not to merge it into M58 at this point. 

rakurati@ I am not sure how you verified this in M58 since the fix never made it to M58. It might just be that the bug is not always reproducible then.

I have verified this on M60.0.3077.0 canary, M59.0.3071.15 beta. Issue is fixed.
Chrome is not freezing based on my earlier steps.
Also Tried the same steps on M58.0.3029.83 and the issue reproduced --> Intended since the issue not merged.

Verified on device: iPhone7, iOS: 10.3.2

Perfect, thanks srikanthg!