Don't add default search engine suggestions to keyword results |
||||||
Issue descriptionChrome Version: 68.0.3407.0 OS: all What steps will reproduce the problem? (1) Install a site search engine, if you don't have one. (2) Enter the site's name in the Omnibox, hit Tab when it suggests "Press (Tab)...", and type a few more chars. What is the expected result? It would be nice if all the results were keyword results from that provider. What happens instead? There will be a what-you-typed search suggestion for the default search engine (e.g. google.com) at the end of the list. The motivation here is not distracting the user when they clearly want results from the site. We might also consider showing a fourth result.
,
Apr 30 2018
Please revert this change. This is the wrong thing to do. It seems really strange that we remove the verbatim but leave the suggestions that come from the default provider. For example, the query "amazon.com show" yields * search for "show" on amazon.com * search for "amazon.com show on google.com * search for "amazon.com showing curtains" on google.com * search for "amazon.com showtime" on google.com * search for "amazon shower heads" on google.com. Only removing #2 seems inappropriate to me. There's a lot more background on why we still have default suggestions (verbatim and otherwise) from the default provider. I'll try to page them back into my memory. In the meantime, please revert this change.
,
Apr 30 2018
,
May 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1310ba0ef28a9d0ad495406ac69168d68863a7ca commit 1310ba0ef28a9d0ad495406ac69168d68863a7ca Author: Kevin Bailey <krb@chromium.org> Date: Tue May 01 00:23:02 2018 Revert "[omnibox] Don't add WYT search in keyword mode" This reverts commit 4a57957a47d1cf544fa0f6ac3f95be4be7c7e407. Reason for revert: mpearson@ would like to discuss it with the team before proceeding. Original change's description: > [omnibox] Don't add WYT search in keyword mode > > When in keyword mode, results will be from that search provider, > except for a single WYT search at the bottom. It looks odd to > have a different search there, when the user asked for a keyword > search. This CL doesn't add the match in that case. > > Bug: 837395 > Change-Id: I1441a6fe07f5d1e7ac5cd3dc16de408df6ad18c9 > Reviewed-on: https://chromium-review.googlesource.com/1030613 > Reviewed-by: Devlin <rdevlin.cronin@chromium.org> > Reviewed-by: Peter Kasting <pkasting@chromium.org> > Commit-Queue: Kevin Bailey <krb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#554762} TBR=pkasting@chromium.org,krb@chromium.org,rdevlin.cronin@chromium.org Change-Id: I95294218cde250794093ce05b85f955f4cb538b2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 837395 Reviewed-on: https://chromium-review.googlesource.com/1036506 Reviewed-by: Kevin Bailey <krb@chromium.org> Commit-Queue: Kevin Bailey <krb@chromium.org> Cr-Commit-Position: refs/heads/master@{#554934} [modify] https://crrev.com/1310ba0ef28a9d0ad495406ac69168d68863a7ca/chrome/browser/autocomplete/search_provider_unittest.cc [modify] https://crrev.com/1310ba0ef28a9d0ad495406ac69168d68863a7ca/chrome/browser/extensions/api/omnibox/omnibox_api_interactive_test.cc [modify] https://crrev.com/1310ba0ef28a9d0ad495406ac69168d68863a7ca/components/omnibox/browser/autocomplete_provider_unittest.cc [modify] https://crrev.com/1310ba0ef28a9d0ad495406ac69168d68863a7ca/components/omnibox/browser/search_provider.cc
,
May 1 2018
> For example, the query "amazon.com show" yields > * search for "show" on amazon.com > * search for "amazon.com show on google.com > * search for "amazon.com showing curtains" on google.com > * search for "amazon.com showtime" on google.com > * search for "amazon shower heads" on google.com. > > Only removing #2 seems inappropriate to me. Sorry, krb, I described this in a hand-wavy way and haven't thought carefully about this problem. I was focused on the WYT match because in the scenarios that I commonly encounter, that's the only one from the default provider. But I think mpearson is correct that the better approach would be for all suggestions from the default search provider (verbatim or otherwise) to be removed. > There's a lot more background on why we still have default suggestions (verbatim and otherwise) from the default provider. I'll try to page them back into my memory. In the meantime, please revert this change. Ok, let us know.
,
May 3 2018
The NextAction date has arrived: 2018-05-03
,
May 9 2018
Removing all suggestions from the default provider I think is somewhat problematic. Two people who regularly use keywords (me and rdcronin) think these backup suggestions are useful. It admit removing default provider suggestions does have some benefits: a conceptually cleaner / clearer dropdown. This is also one way to fix bug 35813. Some questions about how a fix should work: * Should it matter how the user enters keyword word? For example, tabbing into keyword mode is pretty intentional. Typing the keyword, especially one that is short and doesn't look like a hostname, and hitting space could certainly be accidental. For example, some people have "google" as a keyword, and could easily accidentally enter keyword mode. In these cases, the default provider suggestions are what the user is seeking. * If we do this, we should probably eliminate all forms of query suggestions from the non-keyword provider: no what-you-typed, no search suggestions from the server, no search history suggestions, not shortcuts query suggestions that don't correspond with the keyword. I.e., the scope of this might be broader than simply Search provider. * Is the main concern about confusing labeling? If so, then perhaps we shouldn't let suggestions from multiple search engines mix at all. We currently do. For example, if I have the keyword "wikipedia", and I type "wiki testing", I get suggestions for bother "search Google for wiki testing" and "search wiki for testing". (The omnibox matches keywords by prefix.) * Or perhaps this is about type and source of suggestions? Maybe we should suppress all URL suggestions (along with query suggestions) (again regardless of provider), except for those suggested by the invoked keyword. After all, those URL suggestions are coming from an unexpected place (not the keyword search engine). * How common is it for people to use these backup suggestions? We should estimate the effect of the change (from existing UMA logs if possible) or evaluate it. Generally, I think you/we should have a broader understanding of the vision for scoped search before making a change like this. I'm told such a vision is coming. :-)
,
Aug 21
mpearson: Thanks for the detailed notes. I'd like to return to this issue as part of our efforts towards scoped search going forward. The issue I'd like to solve is that keyword search is very powerful and useful but it's difficult to discover and not usable by most users. These limitations result in an outcome where keyword provider suggestions represent a extremely small fraction of all usages (per Omnibox.SuggestionUsed.Provider). We'll be working with UX on approaches to the UI that can more clearly communicate how to enter keyword search mode and what you're seeing once you're there. But I believe the mix of keyword and default results is fundamentally confusing. Any UI treatment, no matter how effective at communicating its purpose and usage to the user will be undercut by functionality that mixes in things that *aren't* keyword search suggestions. You raise some good questions, though. I've put some responses inline below. Let me know your thoughts. > Typing the keyword, especially one that is short and doesn't look like a hostname, and > hitting space could certainly be accidental. Good point and it's true that mixing in default search suggestions offers something of an escape hatch here. If it were up to me, we'd remove the keyword-space mechanism entirely. Anything that might get accidentally triggered by the user that we then have to protect them against seems problematic to me. I don't think it'd be worth the complexity and potential confusion of special casing the behavior based on how the user triggered it, but if we can't get rid of the keyword-space behavior, it'd be worth discussing keeping the mixed results in this scenario. > If we do this, we should probably eliminate all forms of query suggestions from the non- > keyword provider I think that's right. > Is the main concern about confusing labeling? If so, then perhaps we shouldn't let > suggestions from multiple search engines mix at all. Yes, I think that's the correct approach, also. We just shouldn't mix suggestions from multiple search engines. I recognize that every case we currently do this, it has a rationale. But I maintain that it's just fundamentally difficult for the user to use. It's additional cognitive load at best and confusing at worst. > Maybe we should suppress all URL suggestions. Maybe. I'd prefer to have keyword/scoped mode behave like default mode and present a mix of matching search and nav suggestions. But that's dependent on a UI treatment that makes it clear what's happening. > How common is it for people to use these backup suggestions? We should estimate the > effect of the change (from existing UMA logs if possible) or evaluate it. Is this available in existing UMA metrics? If not, the usage (per Omnibox.EnteredKeywordMode) of keyword mode are so small that I'm skeptical of the value of trying to understand the current usage. I get that just because those numbers are small we shouldn't cavalierly disrupt an existing feature. But there's more value in being free to develop a feature that can help a more significant portion of our users. That being said, what I'd like to do in the near term is develop a variation of keyword search behind a flag, so evaluation of the changes should be possible.
,
Sep 4
Re-titling for clarify about what we possibly want here. (possibly because we're unsure if we want it)
,
Sep 12
mpearson: Any thoughts on the discussion in #8? We'd like to proceed (behind a flag for now) with removing DSE suggestions in keyword search mode.
,
Sep 12
Detailed replies to comment #8 below; broader comments follow:
> The issue I'd like to solve is that keyword search is very powerful and useful
> but it's difficult to discover and not usable by most users. These limitations
> result in an outcome where keyword provider suggestions represent a extremely
> small fraction of all usages (per Omnibox.SuggestionUsed.Provider).
"Keyword" provider usage should *not* be used to judge usage of custom search engines.
Normal custom search engine use is handled by Search provider. "Keyword" provider only handles extension keywords, partially typed keywords ("ama harry potter" for amazon.com custom search), and keywords that don't support replacement.
To judge scoped search / keyword usage (roughly), you should compare the Omnibox.EnteredKeywordMode histogram and the Omnibox.NumEvents histogram.
> Good point and it's true that mixing in default search suggestions offers
> something of an escape hatch here. If it were up to me, we'd remove the keyword-space
> mechanism entirely. Anything that might get accidentally triggered by the user
> that we then have to protect them against seems problematic to me. I don't think it'd
> be worth the complexity and potential confusion of special casing the behavior based
> on how the user triggered it, but if we can't get rid of the keyword-space behavior,
> it'd be worth discussing keeping the mixed results in this scenario.
I don't think we can get rid of entering keyword mode with space. The Omnibox.EnteredKeywordMode histogram shows that space is used to enter keyword mode about two-thirds of the times that tab is used. This seems high enough to me if it were accidental, we'd be hearing lots of complaints about it. And since we're not hearing those complaints, most of those uses are not accidental, and thus our users are relying on this way of entering keyword mode.
> > How common is it for people to use these backup suggestions? We should estimate
> > the effect of the change (from existing UMA logs if possible) or evaluate it.
>
> Is this available in existing UMA metrics?
Not really. As stated above, default provider and keyword provider suggestions both normally come from Search provider, so they're impossible to tell apart. You can partially get it by looking to see if there is a SEARCH_OTHER_ENGINE match from Search provider at the same time other matches. To be very narrow, you can look at usage of SEARCH_WHAT_YOU_TYPED from Search provider in the presence of a SEARCH_OTHER_ENGINE match from Search provider. Those would exactly be cases when the user used the default engine what-you-typed (backup) match while in keyword mode.
> We'll be working with UX on approaches to the UI that can more clearly communicate
> how to enter keyword search mode and what you're seeing once you're there. But I
> believe the mix of keyword and default results is fundamentally confusing.
I agree.
> > Maybe we should suppress all URL suggestions.
>
> Maybe. I'd prefer to have keyword/scoped mode behave like default mode and
> present a mix of matching search and nav suggestions.
On second thought, I now agree with you: I don't think we should suppress URL suggestions while in keyword mode (regardless of their source).
More broadly, I'm excited about exploring this space, and I see the motivations for removing default engine suggestions when in keyword mode. I'd like to try this in two separate parts, removing suggestions themselves, and removing suggestions plus removing the default provider search-what-you-typed (backup) match. (I can be convinced to combine the two steps if the backup what-you-typed match is used <0.1% of the time that a keyword provider is invoked. That math is possible to do given data we have.)
> That being said, what I'd like to do in the near term is develop a variation of
> keyword search behind a flag, so evaluation of the changes should be possible.
That sounds good to me.
,
Sep 13
re: space to enter keyword mode, I trigger keyword mode much more than I use it, but I've no urge to complain about it. I'm not sure we should conclude anything from a lack of noise. It seems as though we have such a wealth of data, to many significant digits, and that we should plug a hole in it if we lack specifics. I understand that, to measure this, we'd have to record that a selected suggestion was from keyword mode, and how it was entered. This is probably why we don't have the stats today. But it seems like it would be pretty easy to measure a companion "abandoned keyword mode" (along with the entry mode enumeration.) At that point we have an upper bound. That is, I might enter keyword mode accidentally, say oh well and continue, but that doesn't mean I need the feature to remain.
,
Sep 13
I agree completely that if we had metrics, the space versus tab question could be settled. :-) (Perhaps jdonnelly@, who's clearly watching this bug, will decide to file a bug to add logging for that question and assign it to someone.) I don't like the idea of having different types of keyword suggestion modes depending on how one enters the mode (tab versus space). (I know at some point earlier on this thread we briefly discussed keeping "backup" suggestions if the user entered the mode by a space and not if entered by a tab. I might've brought up this possibility, and for that distraction, I'm sorry.) I like to keep the discussion here about what the keyword mode should look like, and separately worry about whether it's too easy / too hard to trigger. I.e., try to make the space versus tab versus whatever a different discussion. krb@ and jdonnelly@, your thoughts?
,
Oct 2
I guess I feel the opposite. If the user hits space, it's entirely possible that they didn't intend to enter keyword mode. In fact, it's unavoidable, right? In this case, I have no problem showing them a suggestion of 'search for "keyword<space>query"'. But in the case of tab, there's little doubt what they intended. The alternate suggestions are just getting in their way. There's also the consideration of having a fallback. Do we really want to change both inputs at the same time? Even if the user doesn't realize that there's another key that they can hit, at least only a fraction of the population will be affected (if we don't run it through an experiment.) If we went this way, would we like to add a metric to narrow down who exactly is so un/happy ? Or is any un/happiness a good enough indicator?
,
Oct 4
I agree with krb that treating tab and space differently is reasonable thing to try. It's not ideal but I don't think any of the options on the table are. Note that he's taken a swing at this in https://crrev.com/c/1258089/. It's behind our experimental flag so we can all try it out in Canary. Regarding adding a metric, I agree now that we should do this. Is the idea that we'd add a new context to Omnibox.SuggestionUsed.ProviderAndResultType so we could break down Type usage by how the user entered keyword mode, similar to how Omnibox.SuggestionUsed.ProviderAndResultType.ByPageContext works?
,
Oct 4
I'm not sure if the metric proposed in comment #15 makes sense. After all, the information in ProviderAndResultType doesn't actually show whether a suggestion came from keyword mode. Yes, we'd be able to break down, say, search suggestions by how the user entered keyword mode, but we wouldn't know if that search suggestion was the keyword mode suggestion or the backup suggestion. Maybe we want to add to omnibox_event.proto - a top-level bool (was user in keyword mode) - a top-level enum of how the user entered it - a bool for every suggestion whether it came from the keyword associated with the keyword mode (assuming the user is in keyword mode) From that, we should be able to get a slew of information.
,
Oct 5
Ok, that sounds good to me. krb, your thoughts? Can you take a swing at that?
,
Oct 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e7b1b61a49202b5e9fc2fde0e8690d209c24e907 commit e7b1b61a49202b5e9fc2fde0e8690d209c24e907 Author: Wez <wez@chromium.org> Date: Mon Oct 22 18:17:22 2018 Sync metrics protos with google3 - Adds keyword-suggestions fields to omnibox_event.proto. - Renames is_asan_build to is_instrumented_build. Bug: 889105 , 837395 Change-Id: Ic3264ff6052af46770ce63df2d7a189c5643ace3 Reviewed-on: https://chromium-review.googlesource.com/c/1292849 Reviewed-by: Alexei Svitkine <asvitkine@chromium.org> Reviewed-by: Kevin Bailey <krb@chromium.org> Commit-Queue: Wez <wez@chromium.org> Cr-Commit-Position: refs/heads/master@{#601653} [modify] https://crrev.com/e7b1b61a49202b5e9fc2fde0e8690d209c24e907/components/metrics/metrics_log.cc [modify] https://crrev.com/e7b1b61a49202b5e9fc2fde0e8690d209c24e907/components/metrics/metrics_log_unittest.cc [modify] https://crrev.com/e7b1b61a49202b5e9fc2fde0e8690d209c24e907/third_party/metrics_proto/README.chromium [modify] https://crrev.com/e7b1b61a49202b5e9fc2fde0e8690d209c24e907/third_party/metrics_proto/omnibox_event.proto [modify] https://crrev.com/e7b1b61a49202b5e9fc2fde0e8690d209c24e907/third_party/metrics_proto/system_profile.proto
,
Oct 31
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8e517eebc1c3cf190987b44b0eb1332836bc9dfe commit 8e517eebc1c3cf190987b44b0eb1332836bc9dfe Author: Kevin Bailey <krb@chromium.org> Date: Wed Oct 31 14:08:25 2018 [omnibox metrics] Use new Omnibox proto keyword enum Remove the existing Omnibox keyword entry method enumeration and rename all references to new Omnibox event proto enumeration. This will cause Omnibox metrics for these events to begin recording off by one from the previous values, however the histogram enumeration descriptions have been updated too. Bug: 837395 Change-Id: Idd040ac10c64633ae5cbe7b0f7f102776705ef91 Reviewed-on: https://chromium-review.googlesource.com/c/1273624 Reviewed-by: Mark Pearson <mpearson@chromium.org> Commit-Queue: Kevin Bailey <krb@chromium.org> Cr-Commit-Position: refs/heads/master@{#604237} [modify] https://crrev.com/8e517eebc1c3cf190987b44b0eb1332836bc9dfe/chrome/browser/ui/views/location_bar/location_bar_view.cc [modify] https://crrev.com/8e517eebc1c3cf190987b44b0eb1332836bc9dfe/chrome/browser/ui/views/omnibox/omnibox_view_views.cc [modify] https://crrev.com/8e517eebc1c3cf190987b44b0eb1332836bc9dfe/chrome/browser/ui/views/omnibox/omnibox_view_views_unittest.cc [modify] https://crrev.com/8e517eebc1c3cf190987b44b0eb1332836bc9dfe/components/omnibox/browser/omnibox_edit_model.cc [modify] https://crrev.com/8e517eebc1c3cf190987b44b0eb1332836bc9dfe/components/omnibox/browser/omnibox_edit_model.h [modify] https://crrev.com/8e517eebc1c3cf190987b44b0eb1332836bc9dfe/components/omnibox/browser/omnibox_edit_model_unittest.cc [modify] https://crrev.com/8e517eebc1c3cf190987b44b0eb1332836bc9dfe/tools/metrics/histograms/enums.xml [modify] https://crrev.com/8e517eebc1c3cf190987b44b0eb1332836bc9dfe/tools/metrics/histograms/histograms.xml
,
Nov 14
Issue 889445 has been merged into this issue.
,
Nov 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe commit a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe Author: Kevin Bailey <krb@chromium.org> Date: Thu Nov 15 21:48:08 2018 [omnibox metrics] Copy new keyword information into log We added new fields to the Omnibox event protobuf regarding keyword mode. This CL copies the new relevant information from a set of suggestions into that protobuf. Also adds new boolean field to a suggestion. Bug: 837395 Change-Id: I496d5235790a3c3cd1744155fe766b134a366fd5 Reviewed-on: https://chromium-review.googlesource.com/c/1312930 Reviewed-by: Mark Pearson <mpearson@chromium.org> Reviewed-by: Ted Choc <tedchoc@chromium.org> Commit-Queue: Kevin Bailey <krb@chromium.org> Cr-Commit-Position: refs/heads/master@{#608528} [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/chrome/browser/android/omnibox/autocomplete_controller_android.cc [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/autocomplete_match.h [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/base_search_provider.cc [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/keyword_provider.cc [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/omnibox_edit_model.cc [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/omnibox_log.cc [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/omnibox_log.h [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/omnibox_metrics_provider.cc [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/search_provider.cc [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/search_suggestion_parser.cc [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/search_suggestion_parser.h [modify] https://crrev.com/a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe/components/omnibox/browser/shortcuts_provider.cc
,
Nov 21
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03 commit 7c9cf9a9fd1f023e1101b04fb913ff54ee297b03 Author: Sam Maier <smaier@chromium.org> Date: Wed Nov 21 21:15:47 2018 Revert "[omnibox metrics] Copy new keyword information into log" This reverts commit a404b85a11e6cb9ce60eca8548bbaaacd29b3dbe. Reason for revert: Suspected cause of crbug.com/906242 Original change's description: > [omnibox metrics] Copy new keyword information into log > > We added new fields to the Omnibox event protobuf regarding keyword > mode. This CL copies the new relevant information from a set of > suggestions into that protobuf. Also adds new boolean field to a > suggestion. > > Bug: 837395 > Change-Id: I496d5235790a3c3cd1744155fe766b134a366fd5 > Reviewed-on: https://chromium-review.googlesource.com/c/1312930 > Reviewed-by: Mark Pearson <mpearson@chromium.org> > Reviewed-by: Ted Choc <tedchoc@chromium.org> > Commit-Queue: Kevin Bailey <krb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#608528} TBR=mpearson@chromium.org,krb@chromium.org,tedchoc@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 837395 Change-Id: I9c4a39a1d3104a65796d43b31233cc36647f586c Reviewed-on: https://chromium-review.googlesource.com/c/1347031 Reviewed-by: Sam Maier <smaier@chromium.org> Commit-Queue: Sam Maier <smaier@chromium.org> Cr-Commit-Position: refs/heads/master@{#610214} [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/chrome/browser/android/omnibox/autocomplete_controller_android.cc [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/autocomplete_match.h [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/base_search_provider.cc [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/keyword_provider.cc [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/omnibox_edit_model.cc [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/omnibox_log.cc [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/omnibox_log.h [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/omnibox_metrics_provider.cc [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/search_provider.cc [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/search_suggestion_parser.cc [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/search_suggestion_parser.h [modify] https://crrev.com/7c9cf9a9fd1f023e1101b04fb913ff54ee297b03/components/omnibox/browser/shortcuts_provider.cc
,
Jan 8
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/60334f06c3e637c5eecd239635bdbcc80ba37822 commit 60334f06c3e637c5eecd239635bdbcc80ba37822 Author: Kevin Bailey <krb@chromium.org> Date: Tue Jan 08 23:28:12 2019 [omnibox metrics] Reland "Copy new keyword information into log" The original was apparently triggering a protobuf marshaling issue. See http://crbug.com/906242 This version fixes a small issue, adds a sanity check to setting a protobuf field and avoids setting some altogether on mobile. From original: We added new fields to the Omnibox event protobuf regarding keyword mode. This CL copies the new relevant information from a set of suggestions into that protobuf. Also adds new boolean field to a suggestion. Bug: 837395 Change-Id: I9f1f700469bec134175ac2731837861c78f29cfe # TBRing previously approved trivial change. TBR=tedchoc@chromium.org Change-Id: I9f1f700469bec134175ac2731837861c78f29cfe Reviewed-on: https://chromium-review.googlesource.com/c/1351452 Commit-Queue: Kevin Bailey <krb@chromium.org> Reviewed-by: Mark Pearson <mpearson@chromium.org> Cr-Commit-Position: refs/heads/master@{#620929} [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/chrome/browser/android/omnibox/autocomplete_controller_android.cc [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/autocomplete_match.h [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/base_search_provider.cc [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/keyword_provider.cc [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/omnibox_edit_model.cc [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/omnibox_edit_model.h [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/omnibox_log.cc [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/omnibox_log.h [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/omnibox_metrics_provider.cc [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/search_provider.cc [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/search_suggestion_parser.cc [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/search_suggestion_parser.h [modify] https://crrev.com/60334f06c3e637c5eecd239635bdbcc80ba37822/components/omnibox/browser/shortcuts_provider.cc
,
Today
(22 hours ago)
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/489b17d054896796ede1669b0544d18b9b4900b5 commit 489b17d054896796ede1669b0544d18b9b4900b5 Author: Kevin Bailey <krb@chromium.org> Date: Tue Jan 22 14:44:11 2019 [omnibox] Experiment to reduce non-keyword suggestions in keyword mode Under flag, if the user explicitly enters keyword mode, don't show non-keyword suggestions. Bug: 883901, 837395 Change-Id: Iac221e194ce20205e1a40a4ff4a74ea8fec024f6 Reviewed-on: https://chromium-review.googlesource.com/c/1258089 Reviewed-by: Tommy Li <tommycli@chromium.org> Reviewed-by: Justin Donnelly <jdonnelly@chromium.org> Commit-Queue: Kevin Bailey <krb@chromium.org> Cr-Commit-Position: refs/heads/master@{#624775} [modify] https://crrev.com/489b17d054896796ede1669b0544d18b9b4900b5/chrome/browser/ui/webui/omnibox/omnibox_page_handler.cc [modify] https://crrev.com/489b17d054896796ede1669b0544d18b9b4900b5/components/omnibox/browser/autocomplete_classifier.cc [modify] https://crrev.com/489b17d054896796ede1669b0544d18b9b4900b5/components/omnibox/browser/autocomplete_input.cc [modify] https://crrev.com/489b17d054896796ede1669b0544d18b9b4900b5/components/omnibox/browser/autocomplete_input.h [modify] https://crrev.com/489b17d054896796ede1669b0544d18b9b4900b5/components/omnibox/browser/omnibox_edit_model.cc [modify] https://crrev.com/489b17d054896796ede1669b0544d18b9b4900b5/components/omnibox/browser/omnibox_field_trial.h [modify] https://crrev.com/489b17d054896796ede1669b0544d18b9b4900b5/components/omnibox/browser/search_provider.cc [modify] https://crrev.com/489b17d054896796ede1669b0544d18b9b4900b5/components/omnibox/browser/search_provider.h |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by bugdroid1@chromium.org
, Apr 30 2018