Adding some omnibox folks. 

Hmm - my gut reaction is that clicking out of the omnibox without committing an edit/search should probably take you back to the pre-edit state that tells you what page you're looking at (showing icons and URL of the page - NTP might be a special case). That's what we do on mobile where the edit state is quite visually distinct from the steady state. 

One (imaginary?) risk is that people use today's Desktop behavior for complex workflows - ex: to copy and paste a few words from a page into the omnibox one by one as part of query formulation. 

It's definitely WAI but the original intention may or may not be correct.

My $0.02 is that this may be an an annoying case but that the alternatives are worse. Showing the bookmark icon while in edit state would be confusing. Being inside the omnibox is clearly meant to associate it with the URL. Canceling the edit state on focus loss would probably not affect most users but the occasional or even rare case when we threw away an edit state the user wanted to keep would be very unpleasant.

We don't reset the edit state on focus loss precisely because of what comment 1 says: people copy and paste content from the page while editing.  People also interact with the page to scroll down, look at things, etc. to get more information and then go back to editing.  This behavior also matches other browsers and is longstanding.

The URL comes back if the user refreshes, navigates, or cancels the edit by hitting the esc key while focus is in the omnibox.  That's sufficient here.

The real fix for this, as with many omnibox problems, would be to divorce the passive, non-editable control that displays the current URL from the editable control that is always an inviting box to type in.  Sadly, I have no idea how to make that UI come to pass.

Given jdonnelly's and my agreement on this, closing.

The NextAction date has arrived: 2018-01-09