Srikanth, could you please bisect. Also can you repro the problem if instead of Edge Swipe you Tap Back on step 5?

Assigned to eugenebut, but if srikanthg can help bisect would be helpful.

Tapping back button worked fine. Only reproduced with edge-swipe.
I will try to bisect tomorrow and update the bug.

Assigning to Justin for Swipe to Navigate.

Actually this is not a regression. I was able to reproduce this in M61 and M62 also. Also note tapping on back arrow also reproduces the issue. I am not doing any bisect since this is reproduced on M61 as well. Please let me know if you need any other information.

Per comment #4 this looks like Swipe To Navigate bug.

Per comment #5 not related to Swipe To Navigate. Also RBS because the bug leads to URL spoofing. Sorry for the noise.

Can not reproduce with iOS 11, Chromium 64.0.3268.0. Srikanth, do you have any experiments enabled in chrome://flags?

I don't have any special flags enabled other than whats available by default. I am able to repro on M63,62 also.
At step#4, you don't need to scroll down the page as well. Just wait for 5~10 seconds. This websites has lots of requests loading in the background. After ~5+ seconds, tap the back arrow.

I could reproduce with bug on 10.0.2 with iPhone 7 Plus (Rose Gold) using Chrome 62.0.3202.70. Perhaps OS minor version actually matters.

The scary part in this bug is that webView.URL is empty inside webView:didCommitNavigation:. webView.backForwardList.currentItem.URL returns valid URL, which is probably one we should be using everywhere.

Filed rdar://35658290 with ios.gadgetjacks.com. It would be very hard to construct test app without referring to a real web site.

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

commit 4527bad8c9593b16a5ecd883510a4a4a10dcf218
Author: Eugene But <eugenebut@google.com>
Date: Tue Nov 21 20:10:58 2017

Use webView.backForwardList.currentItem.URL if webView.URL is nil.

It is possible for WKWebView.URL to be empty inside
webView:didCommitNavigation:. That's probably a bug, but WKWebView.URL
does not represent last committed URL anyway, so it is safer to fallback
to  WKBackForwardList's currentItem when WKWebView.URL is nil.

Using webView.backForwardList.currentItem.URL everywhere is not an option
because that URL is not correct for WebUI pages loaded via loadHTML:.
After dropping iOS 10 and switching WebUI to iOS 11's custom URL protocols
it might be possible to use webView.backForwardList.currentItem.URL
unconditionally.

Bug:  784480 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I2c2cdb9fad425afec6756bc8e841389e979d066b
Reviewed-on: https://chromium-review.googlesource.com/773621
Commit-Queue: Eugene But <eugenebut@chromium.org>
Reviewed-by: Kurt Horimoto <kkhorimoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518355}
[modify] https://crrev.com/4527bad8c9593b16a5ecd883510a4a4a10dcf218/ios/web/web_state/ui/crw_web_controller.mm

Verified on M64.0.3279.0 canary iPhoneX iOS11.2 beta#5
URL is correctly updated.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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

per comment 12 adding hotlist label.