FWIW when iOS did this I asked them why it was not just being done on all platforms instead of specifically iOS.

We do have Paste and search/Paste and go on desktop that help for mouse users.  We also probably need to worry about how on desktop the clipboard is almost never empty, and we don't want to burn a slot 100% of the time for clipboard contents.

Maybe just doing this when the clipboard contains a URL is a good enough heuristic though.  (Trying to implement some sort of "it was copied recently" thing seems like a nightmare, especially if the copy source is not Chrome.)

UX guidance: show existing omnibox UI with the URL and the title as "Link you copied"

I agree with #2 that we only want to show this when the clipboard contents are a URL.

On iOS, this is also limited by the clipboard contents being less than 3 hours old - can we do that on other platforms?

I don't know how one would do that on Windows, and I'm a little unsure it's the right heuristic anyway.  If we really only want "I just copied this URL", a time frame like 10 minutes might be better.

+1 to only surfacing this for a recognized URL. I also think 3 hours is way too generous a timeout.

I would like this for Android too.

(My personal use case involves having Chrome opened due to clicking a link in another app but wanting to view that page and links from it in an incognito window.  I end up copying the URL from the omnibox, then opening a new incognito tab and pasting the URL in there.  Having the omnibox automatically populated when I create the new tab would save a step.  That said, this particular use case would probably be better solved by either having a generic option in Android to open pages in Chrome incognito or having an option in Chrome to switch the current page into an incognito window.)

Let's implement this behind a flag at first.

I managed to tweak the iOS code for Windows. Can I get UI feedback on the attached screenshot?

UX questions:
1. Is it correct to show the "Link you copied" when the omnibox has focus and:
 a. is empty, or,
 b. the typed text matches the copied link (e.g. "goo" -> "https://www.google.com")
2. Is it correct to show the copied link only once? i.e. if the copied link is shown and the omnibox looses focus, the copied link won't be shown again if it hasn't changed when the omnibox regains focus
2. Is it correct to put the copied link above other suggestions?
3. If we know the title associated with the copied link from history, can we display it instead of "Link you copied"? Or next to "Link you copied"?
3. What icon should be displayed next to the copied link?

Deleted: link you copied.PNG 187 KB

	link you copied.PNG 187 KB View Download

As a non-UI person who's familiar with the omnibox UI idioms, here are my opinions:

> 1. Is it correct to show the "Link you copied" when the omnibox has focus and:
> a. is empty, or,
No, I don't think so.  The screenshot is confusing.  We always try to make the text in the omnibox be equivalent with the top item in the dropdown.  The screenshot above breaks this paradigm.  (I don't have a good suggestion on how to fix it though.)

> b. the typed text matches the copied link (e.g. "goo" -> "https://www.google.com")
I am indifferent about this.

> 2. Is it correct to show the copied link only once? i.e. if the copied link is shown and the omnibox looses focus, the copied link won't be shown again if it hasn't changed when the omnibox regains focus
No, I don't think so.  I often find myself doing something in the omnibox, hitting enter, then realizing oh, I wanted this other suggestion.  Please make the omnibox behavior consistently with the same input.

> 2. Is it correct to put the copied link above other suggestions?
On desktop, putting it below the URL of the current page suggestion (which will be there except possibly on the new tab page) but above all the other suggestions (all of which come from ZeroSuggest) seems reasonable to me.

> 3. If we know the title associated with the copied link from history, can we display it instead of "Link you copied"? Or next to "Link you copied"?
I'd vote for title + "Link you copied" text.  I think users need to understand where this suggestion comes from given that it's disconnected with that they've typed.

> 3. What icon should be displayed next to the copied link?
A page icon, just like any other URLs.  The UI folks have tried to reduce the number of distinct icons in the omnibox.  The page icon seems appropriate.

I've started a discussion of these questions with cleer@, our Windows UXer. I'll respond here by EOD.

Meanwhile though, on 1a: empty omnibox is the core use case for this feature, and what the iOS implementation screenshoted in the original report shows as well. So the answer is yes, unless I've misunderstood something.

Ok, answers from cleer/myself:
1a. yes
b. yes
2. this sounds reasonable to us, but I'd prefer to time-bound it if possible (per #10's reasoning)
2. yes. I'm not sure what the current page suggestion #10 mentions is on desktop - can't seem to get that to come up. Mark, if you feel strongly, please discuss with cleer@.
3. If we have the title, please use "Link you copied - [TITLE]"
3. page icon works great

I think Mark's objection to point 1 in comment 10 revolves around the default action, rather than the use of the string "Link you copied".

I agree with him that the screenshot is problematic on that front.  What this screenshot says is that if you hit enter now, you will navigate somewhere.  But the omnibox is empty, which means that behavior will be greatly surprising to users.

There are two ways to fix this:
(1) Don't be the default action in such a case (in which case you need to have a default action to be in first place instead, or the omnibox framework needs to be modified so handle the case where there is no default action).
(2) Inline-autocomplete your entire URL in this case so it's obvious hitting enter will navigate to it, which will be more helpful but also potentially more surprising/frustrating and might deter people from typing.  You also have the problem that if the user just deleted text in order to get to this state -- i.e. if you're on any other page than the NTP -- then you can't inline-autocomplete, so this solution goes out the window.

Yes, Peter channeled by comment on 1(a) well.  One thing that will help a lot would be *not* to highlight the suggestion in the dropdown and also make sure pressing enter does not do anything.  Highlighting the suggestion implies it is the default action and pressing enter will go there.  On iOS the suggestion is not highlighted and pressing enter does not do anything.  In other words, please make it look / work as it does on iOS.

(As Peter points out, this may require some code.  Currently the omnibox assumes that if the omnibox dropdown is open, there must be a default action.  You'd have to fix this.)

Ah, thanks - I get it now. Not highlighting makes sense, and if it's possible to make the omnibox suggestion drawer open without a default action that seems the best way forward. Open to other suggestions though.

Some parts of the omnibox code may work without a default action, but I suspect other parts rely on there being one, and this reliance may not be terribly obvious.

The way we handle this in similar places today (which we can get away with because this is rare) is that we provide a default match that's non-navigable.  See e.g. what happens when you visit the NTP and just type "?" (at least on Dev).  You get a non-navigable entry to search with Google.

A similar behavior here would be to have a default entry like "<Search or type URL>" that is selected and non-navigable, and put your entry below that.

You would only need this when the omnibox was empty; if you want to handle cases like what ZeroSuggest does, where you provide a match on omnibox focus when there is a visible URL, you don't need to worry about this.

There are pros and cons to this from a UI perspective, but it is for sure easier implementation-wise.  If your goal is "experiment with this on desktop", this is the right way to start.  If your goal is to go straight for a finalized production UI, then we may still want to consider adding the "no default match" support code.

I think the "no default action" solution makes the most sense in terms of "works as expected" and "least user surprise", with the URL being navigable but not highlighted by default.

But if there are potential surprises along the way to implementing that, then pkasting's suggestion of having a selected non-navigable item followed by the URL itself seems like a good initial compromise.

Maybe worth answering the question whether or not we think there are going to be other features that would fit in the non-selected non-default-action use case as well?

We ran an experiment during the InstantExtended work where, in cases where the default match was a verbatim search for what you were typing, we would hide that match (and simply not show a selected default).  I expected this experiment to have positive metrics.  It surprised us when they were negative.  Which is why it didn't launch :)

The actual implementation involved still having the default match under the hood but not showing it.  To apply that to this case, the idea would be to first implement my comment 16 suggestion of "provide a default match that does nothing"; then mark this match as "should be invisible" and make sure it doesn't actually get drawn.  There are some complications, but this is surprisingly easy to implement, and could be used for existing cases like the "type '?'" case mentioned in comment 16 as well.

This might, in fact, be saner ultimately than code that correctly handled not having a default match at all.

> Maybe worth answering the question whether or not we think there are going
> to be other features that would fit in the non-selected non-default-action
> use case as well?

If we ever want to bring the physical web omnibox provider to desktop/laptops (including ChromeOS), that could be another use case.

While it sounds like this would take some work to bring to desktop (per comment #18 and the highlighted default action situation), Android doesn't highlight any suggestions.  That UI clue isn't there.  Thus, I think moving this UI to Android would straightforward and easier than desktop.  Can we simply do that rather than wait to overcome the activation energy to put in the time to make the UI work on desktop?

By the way, Darin mentioned something like this today at a Q&A when asked how Chrome can help users by being smarter.  He said that he frequents a forum where users post URLs that aren't linkified.  He has to painstaking copy and paste it into the omnibox.  Anything that can make this easier: auto-linkifying the text, making contextual search picking it up suggesting the URL navigation, or making the copy-paste journey easier by suggesting the copied link automatically, no paste required.

@#21 - To help improve unlinkified URLs, I wanted to implement the following: http://crbug.com/621720

tldr - replace "Web Search" with "Navigate" if the selected text matches a URL.

I also agree that contextual search should handle URLs well as well to make this even easier if you just tap on them.

I split off the work to make Android work into a separate, blocking bug.

fdoray@, I heard a rumor recently that someone was going to start making this work on desktop.  Do you know anything about it?

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

commit 612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8
Author: mpearson <mpearson@chromium.org>
Date: Wed Mar 01 21:23:58 2017

Omnibox - Make Clipboard Provider Enabled via an Experimental Feature

In the process, revise the list of default providers from a built-in
const to something that's determined dynamically when the omnibox system
is created.

The only interesting part of this changelist is in
components/omnibox/browser/autocomplete_classifier.{h,cc}

Pretty much everything else is downstream changes due to changing an interface.

TBR=mariakhomenko,rohitrao
mariakhomenko for trivial change in chrome/browser/android/omnibox/
rohitrao for trivial change in ios/chrome/browser/autocomplete/

BUG=642114

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

[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/chrome/browser/android/omnibox/autocomplete_controller_android.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/chrome/browser/android/vr_shell/vr_omnibox.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/chrome/browser/autocomplete/autocomplete_classifier_factory.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/chrome/browser/ui/app_list/search/omnibox_provider.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/chrome/browser/ui/views/frame/test_with_browser_view.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/chrome/browser/ui/webui/omnibox/omnibox_page_handler.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/chrome/browser/ui/webui/options/home_page_overlay_handler.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/chrome/browser/ui/webui/options/startup_pages_handler.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/components/omnibox/browser/autocomplete_classifier.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/components/omnibox/browser/autocomplete_classifier.h
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/components/omnibox/browser/omnibox_controller.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/components/omnibox/browser/omnibox_edit_unittest.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/components/omnibox/browser/omnibox_field_trial.cc
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/components/omnibox/browser/omnibox_field_trial.h
[modify] https://crrev.com/612b3dc0d5ab6aaf839cc33e71d5e4f1e49e2bf8/ios/chrome/browser/autocomplete/autocomplete_classifier_factory.cc

revising bug, as clipboard provider is already being launched on Android (see bug 706046).

I do not plan to work on this on desktop.  Marking as available.

Removing label that was not used enough to be worthwhile.

Replacing Hotlist=Reassess-2018 label with NextAction=01/09/2018 per omnibox bug triage doc.

actually remove the obsolete label

The NextAction date has arrived: 2018-01-09

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

I'm told "On all platforms except Mac, [listening for clipboard changes] is fairly straightforward to implement."

The NextAction date has arrived: 2019-01-08