NTP: Incorrect Fakebox vs. Omnibox Determination |
|||
Issue descriptionVersion: 51.0.2704.84 (Official Build) (64-bit) OS: Mac Background information: Omnibox suggestions after explicitly clicking in the "fakebox" (the text box in the middle of the NTP) differ from omnibox suggestions in other context (clicking in the omnibox as normal). When using the fakebox, the omnibox biases promoting searches instead of URLs. What steps will reproduce the problem? (1) Open a new tab. (2) Explicitly click in the fakebox. (3) Type an input such as "mail". (4) Notice the list of suggestion you get. (5) Open a new tab. The omnibox gets focus by default. (6) Type an input such as "mail". (7) Notice the list of suggestion you get. What is the expected output? (8) The two suggestion lists should differ. The first one should have queries more prominent, the second URLs. What do you see instead? (8) The suggestion lists are identical. If in step (5) you explicitly focus in the omnibox by clicking in it, the bad behavior remains. They appear to remain identical--the omnibox remains such as fakebox-ranking mode--until I type do one do the following: - click on an existing tab. The omnibox does not get focus by default. Then explicitly focus in the omnibox and start typing. Now you're back in regular omnibox-ranking mode. (Good.) - have an omnibox edit-in-progress an existing tab. When already in fakebox-ranking mode, click on the existing tab. In this case, the omnibox gets focus by default. Start typing to clobber the text inside. This new text is in omnibox-ranking mode. (Good.) In short, the fakebox focus logic is too sticky. Once you're in fakebox-ranking mode, no matter how you create new tabs or click to focus, you're stuck in fakebox-ranking mode. The only way to get out of it is to either switch to an existing tab and use the omnibox there or navigate to somewhere from the NTP and then use the omnibox on a non-NTP page.
,
Jul 29 2016
,
Feb 27 2017
sky@ writes: What is the key you would use to differentiate the two cases? Clicking on the omnibox? control-l to try to focus the omnibox? mpearson@ writes: Either. Or opening a new tab. Basically, I want the "fakebox" status to only reflect that the user explicitly clicked on the fakebox during this interaction. If the focus is lost and then reappears in the omnibox for some other reason (e.g., due to restoring focus when switching tabs, or explicitly clicking on the omnibox), we treat this as a regular omnibox interaction. sky@ writes: Generally code early outs if the view already has focus. For example https://chromium.googlesource.com/chromium/src/+/master/ui/views/controls/textfield/textfield.cc#599 If you wanted to detect a focus request when the view already has focus you would need to add additional api for this. I have no doubt there are a bunch of early outs you would have to change. sky@ adds: I have a big caveat with adding code like that. You would basically be assuming all secondary calls to request focus should be treated differently. That could have subtle effects. Say the searchbox code I pointed you at happened to call focus twice, it would mean the second is treated differently... Very subtle and easy to miss.
,
Mar 1 2017
I reproduced it again. Basically what's happening here is that once the omnibox/fakebox has focus, it stays in the same mode (omnibox ranking mode versus fakebox ranking mode) until it loses focus. It only loses focus if you focus on the web content. Thus, if you click in the fakebox, then start a new tab, which puts/leaves the focus in the omnibox on the tab, the focus has never left the omnibox/fakebox combo, which means you're still in fakebox ranking mode. Per comment #3, this behavior would be difficult to change. I thought about this and decided the current behavior is okay. If a user is the type of user who focuses explicitly in the fakebox, it's probably okay that if they decide not to navigate somewhere from the fakebox, and open a new tab, that the fakebox ranking mode stays around. It's not a major problem, possibly not even a problem at all, and certainly not worth fixing given the difficulty. |
|||
►
Sign in to add a comment |
|||
Comment 1 by nepper@chromium.org
, Jul 11 2016Status: Available (was: Untriaged)