Issue was reproduced on ipad and ipad pro. On iphone not reproduce.
Also you can watch vidio https://youtu.be/CULhzOWIWYI

The side swipe UI is darker and with an arrow, so this seems to be something inside the WKWebView.  eugenebut@ can you confirm/triage?

This one does not happen in WebShell but is broken in Chrome. I will take a look why web view's frame was changed.

Side SideSwipeNavigationView sets incorrect frame to BrowserContainerView:

* thread #1: tid = 0xe039bf, 0x000000010dad4529 Chromium`::-[BrowserContainerView setFrame:](self=0x00007f9bd4407140, _cmd="setFrame:", frame=(origin = (x = 237.16666666666666, y = 20), size = (width = 768, height = 1004))) + 265 at browser_container_view.mm:35, name = 'CrWebMain', queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
  * frame #0: 0x000000010dad4529 Chromium`::-[BrowserContainerView setFrame:](self=0x00007f9bd4407140, _cmd="setFrame:", frame=(origin = (x = 237.16666666666666, y = 20), size = (width = 768, height = 1004))) + 265 at browser_container_view.mm:35
    frame #1: 0x000000010dd4a34f Chromium`::-[SideSwipeNavigationView handleHorizontalPan:onOverThresholdCompletion:onUnderThresholdCompletion:](self=0x00007f9bd8b01620, _cmd="handleHorizontalPan:onOverThresholdCompletion:onUnderThresholdCompletion:", gesture=0x00007f9bd4301830, onOverThresholdCompletion=0x000000010dd45830, onUnderThresholdCompletion=0x000000010dd45c70)(), void (^)()) + 975 at side_swipe_navigation_view.mm:319
    frame #2: 0x000000010dd45188 Chromium`::-[SideSwipeController handleSwipeToNavigate:](self=0x00006180001a69e0, _cmd="handleSwipeToNavigate:", gesture=0x00007f9bd4301830) + 1960 at side_swipe_controller.mm:415
    frame #3: 0x000000010dd44111 Chromium`::-[SideSwipeController handleSwipe:](self=0x00006180001a69e0, _cmd="handleSwipe:", gesture=0x00007f9bd4301830) + 497 at side_swipe_controller.mm:288
    frame #4: 0x00000001171aa609 UIKit`-[UIGestureRecognizerTarget _sendActionWithGestureRecognizer:] + 57
    frame #5: 0x00000001171b23a8 UIKit`_UIGestureRecognizerSendTargetActions + 109
    frame #6: 0x00000001171afe77 UIKit`_UIGestureRecognizerSendActions + 227
    frame #7: 0x00000001171af103 UIKit`-[UIGestureRecognizer _updateGestureWithEvent:buttonEvent:] + 891
    frame #8: 0x000000011719b1d6 UIKit`_UIGestureEnvironmentUpdate + 1395
    frame #9: 0x000000011719ac1b UIKit`-[UIGestureEnvironment _deliverEvent:toGestureRecognizers:usingBlock:] + 521
    frame #10: 0x0000000117199dfe UIKit`-[UIGestureEnvironment _updateGesturesForEvent:window:] + 286
    frame #11: 0x0000000116ce5f0d UIKit`-[UIWindow sendEvent:] + 3989
    frame #12: 0x0000000116c931a3 UIKit`-[UIApplication sendEvent:] + 371
    frame #13: 0x0000000130e80959 UIKit`-[UIApplicationAccessibility sendEvent:] + 93
    frame #14: 0x000000011746d047 UIKit`__dispatchPreprocessedEventFromEventQueue + 3248
    frame #15: 0x0000000117465cf1 UIKit`__handleEventQueue + 4879
    frame #16: 0x0000000118502311 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
    frame #17: 0x00000001184e759c CoreFoundation`__CFRunLoopDoSources0 + 556
    frame #18: 0x00000001184e6a86 CoreFoundation`__CFRunLoopRun + 918
    frame #19: 0x00000001184e6494 CoreFoundation`CFRunLoopRunSpecific + 420
    frame #20: 0x000000011dd1ca6f GraphicsServices`GSEventRunModal + 161
    frame #21: 0x0000000116c75a34 UIKit`UIApplicationMain + 159
    frame #22: 0x000000010cff4cba Chromium`main(argc=1, argv=0x00007fff52c0c900) + 826 at chrome_exe_main.mm:70
    frame #23: 0x000000012020d68d libdyld.dylib`start + 1

Any update on this Eugene? Is this a regression for 53?

I'm looking at this today.

cmasso@ I have a workaround, but I need to investigate this further and perhaps file a radar.

https://codereview.chromium.org/2281303002

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

commit 95144337ab1af223377554b7ca838de787d8080e
Author: justincohen <justincohen@chromium.org>
Date: Mon Aug 29 14:10:17 2016

Work around PanGestureRecognizer iOS10 issue.

In iOS10, sometimes a PanGestureRecognizer will fire a touchesMoved even
after touchesBegan sets its state to |UIGestureRecognizerStateFailed|.
Somehow the state is re-set to UIGestureRecognizerStatePossible, and ends
up in moved.  Checking if |_startPoint| has been set is a secondary way to
catch for failed gestures. It appears setting failed in touchesMoved still always
works -- this issue only seems to be related to setting Failure in touchesBegan,
and only sometimes.

BUG= 640611 

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

[modify] https://crrev.com/95144337ab1af223377554b7ca838de787d8080e/ios/chrome/browser/ui/side_swipe_gesture_recognizer.mm

cmasso@ this should go in an M53 respin minimum.

[Automated comment] Less than 2 weeks to go before AppStore submit on M53, manual review required.

Your change meets the bar and is auto-approved for M54 (branch: 2840)

[Automated comment] Less than 2 weeks to go before AppStore submit on M53, manual review required.

 justincohen@ I have added this into the list of M53 refresh candidates. Thanks!

Verified  as per the video in  Comment#1 on iPad Air iOS 10 Beta 8 in build 55.0.2842.0 Canary. Content doe snot move.

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

commit 50a444da0b655b362a1ae9d99345e6c78ae8a1d7
Author: Justin Cohen <justincohen@google.com>
Date: Wed Aug 31 18:35:55 2016

Work around PanGestureRecognizer iOS10 issue.

In iOS10, sometimes a PanGestureRecognizer will fire a touchesMoved even
after touchesBegan sets its state to |UIGestureRecognizerStateFailed|.
Somehow the state is re-set to UIGestureRecognizerStatePossible, and ends
up in moved.  Checking if |_startPoint| has been set is a secondary way to
catch for failed gestures. It appears setting failed in touchesMoved still always
works -- this issue only seems to be related to setting Failure in touchesBegan,
and only sometimes.

BUG= 640611 

Review-Url: https://codereview.chromium.org/2281303002
Cr-Commit-Position: refs/heads/master@{#415004}
(cherry picked from commit 95144337ab1af223377554b7ca838de787d8080e)

Review URL: https://codereview.chromium.org/2295283002 .

Cr-Commit-Position: refs/branch-heads/2840@{#76}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/50a444da0b655b362a1ae9d99345e6c78ae8a1d7/ios/chrome/browser/ui/side_swipe_gesture_recognizer.mm

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

commit 792336ddbb2be085276faebbec4a8e83bfd0e989
Author: Justin Cohen <justincohen@google.com>
Date: Wed Aug 31 18:36:56 2016

Work around PanGestureRecognizer iOS10 issue.

In iOS10, sometimes a PanGestureRecognizer will fire a touchesMoved even
after touchesBegan sets its state to |UIGestureRecognizerStateFailed|.
Somehow the state is re-set to UIGestureRecognizerStatePossible, and ends
up in moved.  Checking if |_startPoint| has been set is a secondary way to
catch for failed gestures. It appears setting failed in touchesMoved still always
works -- this issue only seems to be related to setting Failure in touchesBegan,
and only sometimes.

BUG= 640611 

Review-Url: https://codereview.chromium.org/2281303002
Cr-Commit-Position: refs/heads/master@{#415004}
(cherry picked from commit 95144337ab1af223377554b7ca838de787d8080e)

Review URL: https://codereview.chromium.org/2294223004 .

Cr-Commit-Position: refs/branch-heads/2785@{#801}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/792336ddbb2be085276faebbec4a8e83bfd0e989/ios/chrome/browser/ui/side_swipe_gesture_recognizer.mm

Verified on latest chrome beta version on M54 on iPad Air with iOS 10 beta 8 and iPad mini with iOS 10 beta 8, following the video mentioned in comment #1.  Verified that page content should does not move.  Looks good.

This has been merged into 2785. Please verify on 53.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

weird, didn't comment 17 remove merge-approved-54?.

cmasso@ not sure what's going on, I wonder if comment 18 overwrote comment 17.

jparent@ do you know who might be able to look at comment 18 stomping comment 17 (see above)? thanks!

+agable

Aaron, can you look into what is going on with Bugdroid (or Monorail) here?  A label got removed by Bugdroid in comment #17 but then it was back again, without it ever visibly being re-added?  

Thanks, tracking here: https://bugs.chromium.org/p/monorail/issues/detail?id=1747

Hello!

1. In what chrome version fix will available?

2. Also I hope you verify address bar? It should not appear too. Video about address bar issue available on this link: https://youtu.be/mUuf3DVEPpM

Thanks!

+lindsayw@ for verification.

Verified on latest chrome dev version on M53.0.2785.109 on iPad Air with iOS 10 beta 8 and iPad mini with iOS 10.0.1, following the video mentioned in comment #1.  Verified that page content does not move.  Looks good.

This issue also occurs when a touch event has preventDefault called on it. Can be reproduced with this small amount of code: 

document.body.addEventListener('touchstart', function(e) {
    e.preventDefault();
});

Also available at: 

http://codepen.io/davidhartley/pen/4db61a763b2fa588f1478ea634353dce?editors=0110

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

commit 50a444da0b655b362a1ae9d99345e6c78ae8a1d7
Author: Justin Cohen <justincohen@google.com>
Date: Wed Aug 31 18:35:55 2016

Work around PanGestureRecognizer iOS10 issue.

In iOS10, sometimes a PanGestureRecognizer will fire a touchesMoved even
after touchesBegan sets its state to |UIGestureRecognizerStateFailed|.
Somehow the state is re-set to UIGestureRecognizerStatePossible, and ends
up in moved.  Checking if |_startPoint| has been set is a secondary way to
catch for failed gestures. It appears setting failed in touchesMoved still always
works -- this issue only seems to be related to setting Failure in touchesBegan,
and only sometimes.

BUG= 640611 

Review-Url: https://codereview.chromium.org/2281303002
Cr-Commit-Position: refs/heads/master@{#415004}
(cherry picked from commit 95144337ab1af223377554b7ca838de787d8080e)

Review URL: https://codereview.chromium.org/2295283002 .

Cr-Commit-Position: refs/branch-heads/2840@{#76}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/50a444da0b655b362a1ae9d99345e6c78ae8a1d7/ios/chrome/browser/ui/side_swipe_gesture_recognizer.mm