Please watch the video.

Also, in another example, in Screenshot_2 you can see the content of youtube.com is seen with outlook.live.com URL in the omnibox with green lock, and it's definitely bad behavior.

Deleted: screenshot.jpeg 64.3 KB

	screenshot.jpeg 64.3 KB View Download

Thanks for the report. Unfortunately I don't have an iOS device to test this right now, so preemptively adding navigation label.

chromium.khalil: Is the data URL required for this bug? Note that a webpage cannot navigate the top level frame to data URLs.

No, There is no need to thet data URL.

Do you mean it could instead be served over http?

Yes.

I meant we can use a http URL instead of that URL data.

iOS uses a different navigation stack.  Eugene, could you help triage this?

I could not reproduce this bug with 64.0.3282.112 from AppStore. 64.0.3282.97 is not the latest version and I remember we recently fixed one URL spoofing bug for M64.  chromium.khalil, is this bug reproducible with 64.0.3282.112? Thanks.

Yes, I am able to repro this bug on Beta and stable (64.0.3282.112). It sometimes takes several tries to repro. 

Srikanth, can you try reproducing this bug?

I can't repro it so far on M64.0.3282.112 stable app.
Tested on iPhoneX, iPhone8 plus.

Note: When I repro this bug, I can see there is something weird (inside the red square), it seems like the navigation (via backward or forward button) is incomplete or failed which resulted the spoofing URL

Deleted: F4FD91E5-661A-4FB5-9022-615030338792.jpeg 179 KB

	F4FD91E5-661A-4FB5-9022-615030338792.jpeg 179 KB View Download

I found a more reduced test case:

1. Go to any website e.g outlook.com
2. Then go gmail.com (must be logged in)
3. Back to outlook.com 
4. Hold forward button and click on "https://mail.google..." and click quickly on forward button

Also, I was able to repro this with different URLs instead of gmail.com, but it does take several attempts to repro.

I tried with a fresh installation of M64 stable version Chrome app but still no luck.
What version iOS are you using. Can you also copy/paste the contents of about://version page. I will try to repro on few other devices tomorrow.

Google Chrome	64.0.3282.112 (Official Build) stable (64-bit)
Revision	7ceafc6ca46e...
OS	iOS
User Agent	Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_2 like Mac OS X) AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15C202 Safari/604.1
Command Line	--flag-switches-begin --flag-switches-end
Variations	3095aa95-3f4a17df
9e5c75f1-af31fbd4
f79cb77b-3d47f4f4
ef25c1eb-3f4a17df
2d871858-ca7d8d80
494d8760-6843eff2
3ac60855-486e2a9c
4442aae2-6e3b1976
ed1d377-e1cc0f14
75f0f0a0-6bdfffe7
e7e71889-4ad60575

iOS 11.2.2 and I have also tried on 10.3.3.

Weird, I repro-ed this very easily, did you try with gmail.com logged-in as I mentioned in C#16?

RE #21: I wasn't able to reproduce this using a 2017 iPad. 

Reproduction is probably a race condition of some sort, so it may be helpful to know what hardware you were able to reproduce this on?

I’m using iPhone 5 and 6. I’ll try to repro on iPad.

I tried on M64, iPhoneX iOS11.3, iPhone7 iOS11.1.2, iPhone7Plus 10.3.3
Not able to repro. Noticed in some cases tapping on back arrow redirecting to NTP instead of outlook.com but that seems tobe a different navigation bug.
As far as this bug, still trying to repro.
I am signed into gmail.com in content area and in Settings.

Deleted: crbug url not updating repro case.mov 4.7 MB

	crbug url not updating repro case.mov 4.7 MB View Download

You don't have to wait until you accessing the page content of gmail.com, you should click quickly on back arrow after holding (forward arrow) and clicking on "https://mail.google.com...".

Got it. Thanks for the tip.
Bisecting now.

Eugene: I went back upto M61 stable and its reproduced on all of the builds.
Also on M65 and 66 canary.
Let me know if you need any other information from me.
I followed repro steps from comment#26 video.

Root cause:
When the user taps on "gmail entry in history" Chrome loads gmail
When the user taps on Back button Chrome starts loading outlook

After that gmail page creates renderer-initiated navigation. That renderer initiated navigation calls navigationManagerImpl->UpdatePendingItemUrl which overrides outlook.com to gmail.com.

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

commit fcdd81192c7bc9785b62a8f796ea953d681d1d1d
Author: Eugene But <eugenebut@google.com>
Date: Tue Feb 06 02:28:04 2018

Do not create a pending entry for windows opened by DOM.

Creating a pending entry is cruft code from UIWebView world. This
pending invalid new entry is later updated by
NavigationManager::UpdatePendingItemUrl, which is also cruft code from
UIWebView world.

The problem is that NavigationManager::UpdatePendingItemUrl does not
always work correctly and causes ( crbug.com/805900 ). It is necessary to
stop creating an invalid pending entry before removing
NavigationManager::UpdatePendingItemUrl.

Bug:  805900 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: If478c574f11e5e586fac7407085f57ec05079814
Reviewed-on: https://chromium-review.googlesource.com/899700
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534594}
[modify] https://crrev.com/fcdd81192c7bc9785b62a8f796ea953d681d1d1d/ios/chrome/browser/tabs/tab_model.h
[modify] https://crrev.com/fcdd81192c7bc9785b62a8f796ea953d681d1d1d/ios/chrome/browser/tabs/tab_model.mm
[modify] https://crrev.com/fcdd81192c7bc9785b62a8f796ea953d681d1d1d/ios/chrome/browser/ui/browser_view_controller.mm

Thanks for the fix!

This is not the fix yet. But this landed CL should unblock the fix.

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

commit 91fe94ba1ada82a4673f8329dbe243e44f3287f4
Author: Eugene But <eugenebut@chromium.org>
Date: Fri Feb 09 15:04:53 2018

Cleaned up didReceiveServerRedirectForProvisionalNavigation:

Do not call registerLoadRequestForURL: just to update pending item URL.
Use NavigationContext as a source of truth for URL update instead.

Bug:  805900 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: Idb26cf953088a0dafcdb8c80396f2bca93d30c16
Reviewed-on: https://chromium-review.googlesource.com/909704
Reviewed-by: Danyao Wang <danyao@chromium.org>
Commit-Queue: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535711}
[modify] https://crrev.com/91fe94ba1ada82a4673f8329dbe243e44f3287f4/ios/web/web_state/ui/crw_web_controller.mm

What's the update on this blocker. M65 release is nearing

Punting to M66. We need to land a few more CLs to fix the bug and CLs which were landed already are not very safe.

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

commit 03a75113ce67157d31d9743ab7440939271d30cc
Author: Eugene But <eugenebut@google.com>
Date: Wed Feb 14 23:13:57 2018

Change post request to get in didReceiveServerRedirectForProvisionalNavigation.

This was copied from UpdatePendingItemUrl method which will be removed
in a separate CL.

Also reset _lastTransferTimeInSeconds for server redirects.

Bug:  805900 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I79f846c9d4777fc45abff220632a7afc80819d0a
Reviewed-on: https://chromium-review.googlesource.com/914129
Commit-Queue: Eugene But <eugenebut@chromium.org>
Reviewed-by: Danyao Wang <danyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536869}
[modify] https://crrev.com/03a75113ce67157d31d9743ab7440939271d30cc/ios/web/navigation/navigation_manager_impl.h
[modify] https://crrev.com/03a75113ce67157d31d9743ab7440939271d30cc/ios/web/navigation/navigation_manager_util.h
[modify] https://crrev.com/03a75113ce67157d31d9743ab7440939271d30cc/ios/web/navigation/navigation_manager_util.mm
[modify] https://crrev.com/03a75113ce67157d31d9743ab7440939271d30cc/ios/web/net/crw_ssl_status_updater.h
[modify] https://crrev.com/03a75113ce67157d31d9743ab7440939271d30cc/ios/web/net/crw_ssl_status_updater.mm
[modify] https://crrev.com/03a75113ce67157d31d9743ab7440939271d30cc/ios/web/web_state/ui/crw_web_controller.mm

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

commit 74c0d72561c3bea1cb87ba9bfe9f7e7201a1e650
Author: Eugene But <eugenebut@google.com>
Date: Wed Feb 21 22:53:08 2018

Do not update Pending Item URL with URL that have a different origin.

NavigationManagerImpl::UpdatePendingItemUrl exists to update the URL
for redirects. UpdatePendingItemUrl is no longer used for server side
redirects, so this change makes sure that pending item origin is never
changed to prevent URL spoofing bugs.

Conceptually this is not the right fix, because NavigationManager
assumes that there can be only one pending navigation (which is not
true with WKWebView). The right fix would be to switch to WK-based
navigation manager, so this CL is just a workaround.

Bug:  805900 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I20eed4a661244c0fec52a87b088c0620c5f57036
Reviewed-on: https://chromium-review.googlesource.com/923546
Reviewed-by: Danyao Wang <danyao@chromium.org>
Commit-Queue: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538237}
[modify] https://crrev.com/74c0d72561c3bea1cb87ba9bfe9f7e7201a1e650/ios/web/web_state/ui/crw_web_controller.mm

Any bounty for this report? Thanks!

Let's see what the panel says :-)

I'm afraid the VRP panel declined to reward for this bug, citing how much user interaction was required and how it's mitigated. If you have a PoC that requires less user interaction, we could reconsider it.

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