(Note that this has always been an issue, but until recently, the HTTP icon was a simple document icon, like what's still in the dropdown, which looks pretty ambiguous regarding security.  The (i) icon is much more aggressively "hey this isn't secure", which is why I think this is a bigger issue now.)

+max, ainslie as well

Thanks for bringing this up!

I do think we should only show the standard security indicators for loaded sites. Maybe having a grey lock/danger icon would avoid this confusion.

Since we want to unblock the normal icons landing and this might take some UI time, it would make more sense to me to just show the normal page icon during editing (i.e. normal behavior now) than to show the (i) icon for everything. I think this is what was actually intended. 

I don't think I understood that fully.

What do you mean by "only show the standard security indicators for loaded sites"?  My intent was that this bug is about URLs that have not yet been loaded, i.e. while the user is still editing.  (Maybe we mean something different by "loaded"?  It doesn't matter to this bug whether the site has ever been visited before, for example, simply what scheme will be used if the user chooses the current match.)

I'm not sure what confusion is referred to that having a grey lock icon would help with.

I'm not sure how this impacts landing of any iconography.  There should be no new icons needed here, just a bit of plumbing in the omnibox to use the lock when the user's selected match is HTTPS.

I don't know what "show the normal page icon during editing (i.e. normal behavior now)" means.  I can't tell if you're saying "show the lock for an HTTPS match, since that would be its normal icon" or saying "show the underlying icon from the current page" (which we definitely don't want to do for user confusion reasons).  I think maybe the former?

Sorry for being thick :/

I want to note that the fact that the URL is HTTPS doesn't mean that a lock icon will show up when the navigation happens. (The lock icon could be removed or downgraded to a danger icon for a variety of reasons, such as mixed content, an SSL interstitial that the user previously clicked through, etc.)

Is the proposal that we would remember the icon that we showed on previous navigation to the URL and show that in the omnibox? Or that we would always show a gray lock while editing for any HTTPS URL?

The latter.  Even if we tried to remember what happened before, nothing says the site hasn't changed such that what happens this time will be different, so that route is still misleading if the desire is to communicate "what will ultimately happen after I connect".

I think it's OK -- preferable, even -- for the omnibox to show you what it thinks the immediate navigation result is, rather than the ultimate navigation result.  My thought experiment for this is redirects -- let's say that foo.com redirects to bar.com.  If typing "foo.com" showed you a dropdown entry reading "bar.com", you would likely be quite confused.  It's better to show what you're going to do immediately (foo.com) and let what happens after that happen.

I think this will still be better than what we do today.

Sorry for the confusion! I will try to elucidate below:

>> "only show the standard security indicators for loaded sites"
I meant "standard" to mean green lock coloring -- we should only show the *green* lock when the navigation to the HTTPS site happens. We need the grey color distinction for editing. This is also the "confusion" I was talking about.

>> "I'm not sure how this impacts landing"
shrike did some work in https://bugs.chromium.org/p/chromium/issues/detail?id=604520#c44 to reimplement the new icons in code and I was concerned this additional omnibox plumbing would complicate things and be hard to cherry-pick back to 52 for Mac

>> "show the normal page icon during editing"
I was referring to the literal page icon. (Literally, the icon that looks like a page, which is still in the omnobix dropdown). Right now, during any editing, we show the page icon, right? I was saying "continue that behavior -- always show the page icon during editing". 

Thanks for the clarifications.  I am less confused now :)

* Agree on using a grey lock (or more precisely, using a lock whose color matches the color of the other icons we use during editing) rather than green.

* I think it would be fine for any work here to happen in 53.  I would not worry about this for 52, it's a nice-to-have and not a blocker.  (If it's simple to get in 52, I won't object.)

* On trunk, we do not show the "page" icon in the omnibox during editing -- instead we show the (i) icon.  Hence this bug.  This is because the omnibox icon during editing isn't picked from among the dropdown icons; it uses whatever icon we use for "normal HTTP URL".  That used to also be a "page" icon, which was a reasonable generic placeholder icon.  Now it's the (i), which is less generic.  So, we could do as you suggest, and use a "page" icon during editing.  It's not really going to be much simpler to do one versus the other (I think), so we should just pick what we want the long-term behavior to be and do that.

One thing I am a bit concerned about is the parity between omnibox icon and dropdown icons. It seems a bit weird to have a different icon in the omnibox and the dropdown selection (see attached, but assume (i) is now a grey lock). 

OTOH it also feels weird to have (i) icons in the dropdown, since they would not be clickable, and I think the purpose of the (i) is to invite a click to learn more about HTTP.

#9: Missing screenshot?

Yeah, I would not use (i) in the dropdown for that reason.  Given that I'm OK with the dropdown using a generic "document" icon to mean "URL".  It is inconsistent, but that seems less wrong to me than the alternatives.

I think +edwardjung@ and maxwalker@ have been thinking about this space as part of their UX prototyping efforts so it'd be good for them to weigh in.

Showing the page icon in the edit/dropdown state and the security icons (lock, info, triangle) for connection security is what we have been proposing in the Omnibox PRD. It never made sense to me that the page icon represented both page suggestions (as the search icon represents search suggestions) and HTTP connection security.

Deleted: States.png 171 KB

	States.png 171 KB View Download

So just to be clear:

* Situation in past releases: dropdown always uses "page" icon, omnibox always shows page icon when editing, omnibox uses page icon for HTTP and lock icon for HTTPS when not editing

* Situation today: dropdown uses "page" icon, omnibox always shows (i) icon when editing, omnibox uses (i) icon for HTTP and lock icon for HTTPS when not editing

* My proposal: like current situation, but use the non-editing icons while editing

* Your proposal: like old situation, but use the (i) icon for HTTP when not editing

My proposal has the downsides that the omnibox wouldn't match the dropdown while editing, and the final HTTP[S] state might not match the state shown while editing.  Your proposal has the downsides that the page icon isn't used outside editing (possibly making its meaning unclear), and the editing state is less clear-at-a-glance about whether the current URL is likely to be secure or not.

If I have all that correct, I am OK with either proposal as both seem better than the current situation.

* Your proposal: like old situation, but use the (i) icon for HTTP when not editing

This is the proposal that Max and I agreed on when doing the animation. So we never use the connection ((i), warning triangle and lock) icons during editing, only when the connection status is known.

OK, let's make that change then.

I'll start in on this this week.

Moving this nonessential bug to the next milestone.

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

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

commit 79f10e462b13f6fafdbe2fe50b0eda048359fdf6
Author: palmer <palmer@chromium.org>
Date: Fri Jul 22 03:45:57 2016

Use the Blank Page icon when editing a non-search Omnibox query.

BUG= 617887 

Review-Url: https://codereview.chromium.org/2149673003
Cr-Commit-Position: refs/heads/master@{#407042}

[modify] https://crrev.com/79f10e462b13f6fafdbe2fe50b0eda048359fdf6/components/omnibox/browser/omnibox_view.cc

I think https://codereview.chromium.org/2149673003 gets us to where we want to be on this bug.

I can't confirm the change on Chrome 54.0.2807.1/OSX 10.11.6. Are there specific repro steps I can follow?

No idea if this is fixed on Mac.  Type a URL in the address bar, without hitting enter, and make sure the icon next to it looks like a document and not an (i).  Similarly, any URLs in the dropdown should be document icons, not (i)s.

On 54.0.2808.0 Mac Canary the info icon still shows up while the page is loading (page > info > lock), which seems distracting for non-HTTP sites.

Deleted: Info.gif 899 KB

	Info.gif 899 KB View Download

I don't think we can do anything about that.  You typed an HTTP URL, not an HTTPS one, so when the load commits, the (i) is the correct icon.  It's only after it redirects that the icon changes to a lock.

We do coalesce rapid changes to this in some cases, which could lead to things like "when I looked on Windows I didn't happen to see this", but unless Mac lacks that coalescing I wouldn't think this is a Mac bug.

This also happens when loading a HTTPS site without redirects.

Deleted: Load.gif 1.7 MB

	Load.gif 1.7 MB View Download

I would file a new bug for that, assign to palmer, and CC me; we should probably make sure we understand how the toolbar model is deciding the security state here and see if it should optimistically guess that HTTPS will be secure if the navigation is still pending and not yet committed.  I think we did something like that for Instant Extended for search term replacement, to avoid flicker, so hopefully the code is already there.

Thanks, Peter! Filed a bug: https://bugs.chromium.org/p/chromium/issues/detail?id=632298