59 bytes, text/x-review-board-request
We currently show local results first and remote results second, as distinct groups. This means that if the user is doing an information search, the best result we have to offer is buried deep down in position 7, most of the time. Conversely, with bug 1359899 remote results would be on top and if the user is doing a navigational or recovery search our best result would likely be again in position 7. In order to make sure our best results for every kind of query (informational, navigational, recovery) are visible, we should surface the best of both kinds to the top of the results panel. This change is about enabling experiments, so it should be controlled by a pref.
Should this bug also include the experimentation part? Other required stuff? The pref from bug 1359899 should already allow to do this.
This bug is just about implementing the part that controls this capability via a pref. If this is done we can resolve it. Can we use the pref to show a different type of result in position 2, depending on what type of result autofill in position 1 is?
(In reply to Panos Astithas [:past] (please needinfo?) from comment #2) > This bug is just about implementing the part that controls this capability > via a pref. If this is done we can resolve it. yes, that is done. > Can we use the pref to show a different type of result in position 2, > depending on what type of result autofill in position 1 is? Not in the current shape, it's tricky to have dynamic behavior from a static pref. At a maximum we could double the pref (one for search, one for local), but to me it's still totally unclear how we distinguish a search environment from a non-search environment, I didn't see any valid heuristics proposed yet. Or at least, nothing that can tell if "node.js" is a url or a search.
I'm going to split the current pref into 2, one per context (search or general).
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Summary: Top remote and top local results should appear in positions 1 and 2 → Allow the urlbar prefs to define different buckets for different contexts
Comment on attachment 8888831 [details] Bug 1378035 - Allow the urlbar prefs to define different buckets for different contexts. https://reviewboard.mozilla.org/r/159860/#review165230 ::: toolkit/components/places/UnifiedComplete.js:533 (Diff revision 1) > + ...store.matchBucketsSearch, > + ...DEFAULT_BUCKETS_AFTER ]; nit: indentation
Attachment #8888831 - Flags: review?(paolo.mozmail) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/01e0c8b8e581 Allow the urlbar prefs to define different buckets for different contexts. r=Paolo
You need to log in before you can comment on or make changes to this bug.