New issue
Advanced search Search tips

Issue 756770 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 632361



Sign in to add a comment

Consider using no-state prefetch for zero-suggest on android

Project Member Reported by mattcary@chromium.org, Aug 18 2017

Issue description

We should consider using no-state prefetch on the top-ranked most-visited suggestion on omnibox focus on android. These are offered on omnibox on non-NTP, non-search-result-page URLs. The triggering would have ~13% accuracy: 

https://uma.googleplex.com/p/chrome/histograms/?endDate=20170813&dayCount=1&histograms=Omnibox.PageContext%2COmnibox.SelectedPosition.ZeroSuggest&fixupData=true&showMax=true&filters=platform%2Ceq%2CA%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

(Compare zero suggest click position 1 by the count of uses of the omnibox on "other" page category URLs, which are the non-NTP, non-search-result-page URLs)
 
Cc: lizeb@chromium.org
Another option might be to preconnect rather than doing a full prefetch. This might be less wasteful and may still get most of the benefit. Adding lizeb@ for preconnect info.
Components: UI>Browser>Omnibox>ZeroSuggest
Labels: Performance-Loading
Cc: alexilin@chromium.org
+alexilin

Alex: can you summarize what the current preconnect experiment doing w/rt omnibox zero-suggest?

Thx
The current experiment doesn't change existing behavior of how omnibox provides hints for preconnect. The decision about what type of pre* action to do is made inside the ChromeOmniboxClient. This class doesn't currently use any information about whether omnibox match corresponds to zero-suggest or not.

IIUC, ChromeOmniboxClient issues a preconnect after a zero-suggest only if a prerender is disabled. https://cs.chromium.org/chromium/src/chrome/browser/ui/omnibox/chrome_omnibox_client.cc?rcl=6a986948a587cc5a45db73984329ee56d669a058&l=336
Status: Fixed (was: Assigned)
Ah, which means that we are already doing preconnect (as prerender is now disabled).

Thanks!
Status: Available (was: Fixed)
Actually not.
ChromeOmniboxClient uses PrerenderManager::IsAnyPrerenderingPossible() to determine if a prerender is disabled. This function returns false only if the PRERENDER_MODE_DISABLED mode is used. But the current default value for a prerender mode is PRERENDER_MODE_SIMPLE_LOAD_EXPERIMENT. We should probably  change this behavior.

I also forgot to mention that we actually do preconnect only for search URLs from an omnibox. For the rest we preresolve hosts. See  AutocompleteActionPredictor::IsPreconnectable().
Thanks for the clarification. We should coordinate this with the nostate test.
Blocking: 632361
I'm sorry, everything I've described in c#4 and c#6 is applicable only for desktop. On Android we don't do preconnect from the omnibox at all. OmniboxPrerender seems to be the right place to add this functionality. It basically repeats the code from ChromeOmniboxClient::OnTextChanged. And there is even "TODO (apiccion) add preconnect logic" added back in 2013.

And by the way, we already may do no-state prefetch from the OmniboxPrerender if AutocompleteActionPredictor has high confidence (never happen for empty input though) and if no-state prefetch is enabled.
Status: Assigned (was: Available)
Cc: tbansal@chromium.org
tbansal: FYI

Sign in to add a comment