Issue 862177  has been merged into this issue.

I'll investigate.

manukh, thakis, mpearson: I believe that https://crrev.com/c/1114337 ("reset display url when re-navigating to the current page by clicking a link") is causing this issue. It looks like the NTP load is triggering the same code path that the reload-same-page case is using to reset the URL. But NTP load happens independently of a link click, so it can happen while the user is typing in the omnibox.

Any thoughts on whether this RevertToolbarUrl() call could be made conditional on the NTP case?

https://crrev.com/c/1114337/9/chrome/browser/ui/browser.cc#2213

> Any thoughts on whether this RevertToolbarUrl() call could be
> made conditional on the NTP case?

That doesn't feel like the right answer to me.  This is a race condition, and nothing here makes it sound like the race condition is limited to the NTP.  (Can a slow-loading other page trigger this too?)

By the way, I always look skeptically at changes that are limited to certain type of pages.  For example, would we want to limit this to Google-default-search-engine NTPs (partially server-powered NTPs), other-default-search-engine NTPs, extension-replaced NTPs?  As the answer to this isn't obvious to me, it makes me concerned that this approach is wrong.

It we don't have a solution, it might be worth reverting the original change.  The original bug is mild, and we can live with it for more releases.

JDonnelly@, regarding differentiating the two paths (re-navigation v. ntp load):

Following the code flow upwards, the first distinction appears at WebContentsImpl::NotifyChangedNavigationState, which is only invoked when navigating via links and not when navigating via the location bar or opening a new tab or window. The flow after NotifyChangedNavigationState's invocation is: 

1 WebContentsImpl::NotifyChangedNavigationState
2 WebContentsImpl::NotifyNavigationStateChanged
3 Browser::NavigationStateChanged
4 Browser::ScheduleUIUpdate

WebContentsImpl sounds like it manages the main html rendering. Maybe it's reasonable to move the trigger for resetting the omnibox text from Browser::ScheduleUIUpdate to WebContentsImpl::NotifyChangedNavigationState or further up the chain?

I tried moving the trigger to WebContentsImpl::NotifyChangedNavigationState, and it seems working.

Special-casing in the general case is usually the wrong approach, as Mark says in comment 6. WebContentsImpl is deep in content/. NTP special-casing would absolutely not be allowed in it, as it compounds the usual issues with layering issues (content/ should not know about embedder things like the NTP).

 Issue 862673  has been merged into this issue.

Renaming (omnbox->omnibox) to make this crbug easier to find.

#6: no, I haven't been able to trigger this issue with regular page loads. Which is not to say that it's impossible, but for the moment the issue seems specific to the NTP.

But I think you're right to be concerned about trying a quick fix here. Given the severe nature of the issue here and the dangers of getting a fix wrong, especially soon before the branch point, I'm going to try reverting https://crrev.com/c/1114337.

For reference, here's the revert, which landed on 13 July: https://crrev.com/c/1134099.

 Issue 864627  has been merged into this issue.

Issue 865473 has been merged into this issue.

 Issue 866222  has been merged into this issue.

Unable to reproduce the issue on Win-10 using chrome reported version #69.0.3487.0.
Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
(1) Opened control-n.
(2) Immediately started typing something like 'chromium'
(3) Did not observe text getting clobbered.

Hence, unable to verify the issue on latest chrome version #70.0.3500.0.

jdonnelly@/sky@ - Could you please check the screen cast and please help us in verifying the fix.

Thanks...!!

Deleted: 862196.mp4 915 KB

	862196.mp4 915 KB View Download

krajshree, you are waiting too long between the time you type control-n and start typing. You have to type something before the new tab finishes loading to see the bug.

Just to update, couldn't repro the issue on the reported version 69.0.3487.0 on Windows-10, Mac OS 10.13.3 as well.