Can somebody confirm this on Mac (doesn't reproduce on ChromeOS or Linux) and suggest an owner?

Duplicated in 69 on Mac. Canary (71.0.3543) works fine. (Shows correct URL.)

jdonnelly@: This appears to be a regression from the new omnibox refresh in M69, probably related to how the text changes when you click in the omnibox.  If you double click on the omnibox and *then* the page in the tab navigates while the text is selected, we're not resetting the omnibox text to the new URL the way we did in Chrome 68 and before.

Contrary to comments 1 and 3, I can repro this bug on all Chrome 69+ versions/platforms: Windows/Mac/Linux Stable 69.0.3497.81, Mac Canary 71.0.3543.0.

I agree with Medium severity, since it's a URL spoof that has mitigating factors (it depends on the user double clicking at the wrong time).

I expect there's some reset that used to happen in the omnibox logic and doesn't happen anymore.  It is possible to hit Escape to see the new URL, but that didn't used to be necessary, and we should fix that.  Any ideas where to look in the new code?  Thanks!

Hmm, that's weird-- I could have sworn I saw it on Mac Canary 71.0.3543.0, but now I can't repro it there (or on Windows Canary).  Maybe this is fixed after all.  I'll try to bisect to see what I come up with.

Ah!  I was having trouble bisecting because the bug only occurs when the OmniboxUIExperimentHideSteadyStateUrlSchemeAndSubdomains feature is enabled.  That's enabled by default in Finch, but it doesn't apply to the first run, which is what I was seeing when bisecting (thus I never observed the bug there).

I'm trying again after manually enabling that feature during bisect.  tommycli@, I'm guessing you're familiar with it based on r526096.

Indeed!  This was fixed by tommycli@ in r584056 for  issue 875002 .  Sadly, that landed in 70.0.3526.0 and was not merged to M69.

tommycli@: Would this be a safe merge to M69?

awhalley@: Do you think we should merge it to M69 given the Medium severity?  There's a mitigating factor that the user has to select text in the omnibox to unelide it, but after that the attacker can load any URL they want underneath it without updating the omnibox.

It's been in dev for a good couple of weeks, and the fix is nice and straight forward; I'd support a 69 merge. 

I support a merge to 69. Merge request for the below patch:

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

commit 02035ae5926720d49bcd4a1bae42df4ffd6ac158
Author: Tommy C. Li <tommycli@chromium.org>
Date: Fri Aug 17 14:14:52 2018

Omnibox: Steady State Elisions - Reset URL unless user has edited it

Currently, if the user has unelided the URL, the URL won't reset on
navigation.

Instead, we should only only preserve the URL if the user has actually
made modifications, rather than merely uneliding the URL.

Bug:   875002  
Change-Id: Ie138ee9a0b4cf7d7d903d600a739deb2378de29c
Reviewed-on: https://chromium-review.googlesource.com/1178631
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Commit-Queue: Tommy Li <tommycli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584056}
[modify] https://crrev.com/02035ae5926720d49bcd4a1bae42df4ffd6ac158/components/omnibox/browser/omnibox_edit_model.cc

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

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

Approving merge to M69 branch 3497 based on comments #10,#11 and #12. Please merge ASAP.

Merge to 69 has been submitted: https://chromium-review.googlesource.com/c/chromium/src/+/1210542

Thanks.

Thanks all!

tommycli@ to verify on M69 on Monday, 09/10.

I've verified that this bug is fixed in the staging build of 69.0.3497.87 on Mac, using --enable-features=OmniboxUIExperimentHideSteadyStateUrlSchemeAndSubdomains.  (As noted in comment 9, that feature is required to see the original bug, and it's enabled by default but not present on the first run in a profile.)

The NextAction date has arrived: 2018-09-10

Thanks. creis verified in c#21.

*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

Nice one evi1m0.bat@! The VRP panel decided to award $1,000 for this report - thanks!

Thank for reward :)

Pardon the delay. A CVE has has been allocated for this bug, and https://chromereleases.googleblog.com/2018/09/stable-channel-update-for-desktop_11.html updated accordingly. Cheers!

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