Hitting ctrl-k with inline autocompletion or temporary text results in surprising (?) query string |
|||||
Issue descriptionTom, assigning to you because you've done a lot of thinking in this area and I want your opinion on what we should do here. This is minor though, so feel free to backburner any actual fixes. Here are two different obscure cases that demonstrate this issue. (1) (Less obscure) * Type something that triggers inline autocompletion * Hit ctrl-K (2) (More obscure) * Type anything in the omnibox that gets you dropdown entries * Arrow to a non-default entry * Hit ctrl-K In both cases, you will now be in keyword mode with your default search provider and some visible query string. Before reading further, answer this: what would you expect the query string to be? Here are my answers. In case 1, I expected the query string to be the visible text, i.e. including the inline autocompletion. In case 2, I expected the query string to be the visible (i.e. temporary text). In both cases, the current behavior is that the query string is the user text (the original typing sans autocompletion). Below this are more rambling thoughts. You can skip them if you want. I can see a weak consistency argument for our current behavior in case 1. If you type, get an inline autocompletion, and then hit ctrl-enter, we ignore the inline autocompletion and append ".com" to your original typing. And if you have exactly typed a particular keyword, and have an inline autocompletion to another keyword, and hit tab, we'll toggle to search mode using the keyword you typed, not the autocompleted one. Both these behaviors were originally the other way, but changed over time because people wanted the inline autocompletion to be "less aggressive" about overriding what you were doing. But I'm not convinced ctrl-K should entirely ignore inline autocompletions. In both the above cases, the reasonable flow to use to trigger the features in question is to type first, then trigger them. With ctrl-K, however, people normally trigger it before typing. If they trigger it after, we worry enough that they meant to start a new action that we select the whole query, so further typing will just nuke it. We preserve the (now selected) query in case they meant to keep it, but clearly this isn't thought to be the common use case. So I don't expect similar pressure to back off a behavior that ctrl-K "just searches for the visible text". I say all this because to me the behavior in case 2 is really weird -- searching for your original typing after you've gone to the trouble of arrowing to something else seems clearly wrong. But if we fix that, I think it makes sense to make case 1 also respect the "visible text" for consistency reasons. One might then ask "what about ctrl-K when there's no user text at all -- when we're just showing the permanent text? If you want consistency, then surely this should go into search mode, but leave the existing URL visible and just select it. Not only is that consistent with your arguments above, it's more consistent with what ctrl-L does." My kneejerk reaction to this was "ugh". My considered reaction is "I don't think we should do that, but it isn't quite as terrible as I thought". I don't think it's very helpful, though, and I don't think there's as much consistency argument here as there might appear to be (typing and hitting ctrl-K, versus hitting ctrl-K and then typing, arguably signal different intents). So I wouldn't change this.
,
Oct 19 2016
My two cents: Agree with Peter and Tom about (1) and (2) (including Tom's suggestions about selections). Control-K on permanent URL -> empty query string. I can be convinced otherwise; it's also reasonable to highlight the current URL so trying clobbers it. I have two reasons for this suggestion. One, we put text in the omnibox to provide examples of what's reasonable to do (full URLs, the hint "Type query or URL", etc.). Putting a URL in the omnibox when in search mode is not what we should be encouraging people to do. It's not something regularly users should want to do. Two, I have a sense that the people who use control-K as the same people who use the keyboard shortcut to go to the search box on firefox, and that box starts out empty so I think starting out blank is what the users expect. I don't like the idea of putting a test in case (2) for "if is URL then do X otherwise Y".
,
Oct 19 2016
Mark fleshes out more of why I didn't want to change the "ctrl-k when permanent text is showing" behavior from what we do today. I feel reasonably confident in our current behavior. Regarding the end of comment 1, I wouldn't change the behavior based on whether the text is a URL. I think the consistency problems of doing this are worse than the consistency problems of not doing it (but leaving our permanent text behavior as it is today). What does "if previous selection was empty" mean? Does that only mean "the box didn't have focus", or does it include "box had focus but the selection range was collapsed"? For example, if I arrow to a temporary item, then arrow left/right, so my cursor is in the middle of the text, then hit ctrl-K, do we select the whole thing or leave the cursor where it was? * If we leave it where it is, I think we basically have to change the existing behavior where hitting ctrl-K with typed text will select everything you typed. Changing that behavior feels like it maybe makes things "less surprising" but also possible "less useful". * If we select the whole thing, I kinda think we should select the whole thing in cases where there was already an existing selection as well. I don't really understand why "type goo, get no autocompletion, press ctrl-K" selects "goo", but "type goo, get autocompleted to google.com, press ctrl-K" selects "gle.com". With more thought, I feel like the second bullet here is what I prefer. So here's my proposal. When the user hits ctrl-K: * If the permanent text is showing, clear it. Otherwise, use the existing text in the view as the new search query. * Select the whole search query.
,
Oct 19 2016
I want to avoid the following case: 1. User types "go" 2. Gets autocompleted to "google.com" and "ogle.com" is selected 3. Press ctrl+K 4. Oops, they actually meant to search for "go language" 5. Now they have to press right arrow and backspace until they're left with "go" (or redundantly retype "go" since everything is selected) 6. Type " language" We shouldn't select the user_text, because the user _just_ typed it, why would they now want to get rid of it? Now that I think about it, I can't actually think of a case where I would want the text to be entirely selected (that's what ctrl+L is for). I don't want software trying to "figure out" what I meant. I meant what I typed. Anything more is just getting in the way. My revised proposal is basically pkasting@'s first bullet point: When the user hits ctrl-K: * Use the display text as the query text (unless it's the permanent URL, in which case use "" as the query text). * Don't touch the selection. I'm not fully convinced of this: "If they trigger [ctrl+K] after [typing], we worry enough that they meant to start a new action that we select the whole query, so further typing will just nuke it." If you can convince me that that case is more common than my case, then I would agree bullet 2 is the right solution.
,
Oct 20 2016
To summarize for my own brain, it seems like there are four use cases. 1) Hit ctrl-k and type a search. 2) Type some, change mind, hit ctrl-k, and type something else. 3) Type some, realize this was supposed to be forced to be a search, hit ctrl-k, and continue editing. 4) Type a search, then hit ctrl-k. Since we're agreeing on nuking the permanent text, case 1 is handled. Since none of our suggestions throw away the user's typing, they all handle case 4. Preserving selection handles case 3, at the cost of making case 2 annoying. Selecting everything handles case 2, at the cost of making case 3 annoying. So the issue is whether we care more about case 2 or case 3. I claim that case 2 is more important. People are going to use these shortcuts at the start of new actions more than anything else. If I was ranking the frequency of the above cases, it would be 1, 2, 4, 3. The origin of ctrl-k is as a "focus search box" shortcut parallel to ctrl-l. If you have typing in it already, hitting ctrl-k selects all that typing, so it can be used as a quick "nuke what I was doing and try again" shortcut. We wanted the omnibox to feel like it mapped back to the original two-box UI as closely as possible.
,
Oct 20 2016
Ok, I'm fine with your solution if you believe case 2 is more common than case 4. +some UI folks in case they have any strong opinions
,
Oct 20 2016
,
Oct 20 2016
,
Oct 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/795d4bec22b00f41f4a87e193494a728d73aa72d commit 795d4bec22b00f41f4a87e193494a728d73aa72d Author: thomasanderson <thomasanderson@google.com> Date: Tue Oct 25 23:42:03 2016 Omnibox: Preserve display text and select all on a focus search BUG= 657243 R=pkasting@chromium.org Review-Url: https://codereview.chromium.org/2435103002 Cr-Commit-Position: refs/heads/master@{#427535} [modify] https://crrev.com/795d4bec22b00f41f4a87e193494a728d73aa72d/chrome/browser/autocomplete/autocomplete_browsertest.cc [modify] https://crrev.com/795d4bec22b00f41f4a87e193494a728d73aa72d/chrome/browser/ui/cocoa/omnibox/omnibox_view_mac.mm [modify] https://crrev.com/795d4bec22b00f41f4a87e193494a728d73aa72d/chrome/browser/ui/omnibox/chrome_omnibox_client.cc [modify] https://crrev.com/795d4bec22b00f41f4a87e193494a728d73aa72d/chrome/browser/ui/omnibox/omnibox_view_browsertest.cc [modify] https://crrev.com/795d4bec22b00f41f4a87e193494a728d73aa72d/chrome/browser/ui/views/omnibox/omnibox_view_views.cc [modify] https://crrev.com/795d4bec22b00f41f4a87e193494a728d73aa72d/components/omnibox/browser/omnibox_edit_model.cc [modify] https://crrev.com/795d4bec22b00f41f4a87e193494a728d73aa72d/components/omnibox/browser/omnibox_edit_model.h
,
Oct 25 2016
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by thomasanderson@chromium.org
, Oct 19 2016