Closed Bug 1181605 Opened 4 years ago Closed 4 years ago
search suggestions in the awesome bar need to set a purpose for get
STR: 1. Using Yahoo as default, type a term that triggers search suggestions, and select one of the suggestions. 2. Note the different result page style, and "yhs-invalid" in the URL. 3. This means we get the wrong result page AND it won't get tracked as a partner search. Also impacts any engine that has purpose-specific args such as Bing/DDG, though the bustage is just around tracking codes. Results okay, no partner credit. This needs to block Fx41, marking accordingly. Simple fix coming here that'll be branch-safe, will file a bug on the core issue around getSubmission as well.
bug 1071361 is related, it depends on bug 1063530 but here we don't need all of that code and feature. We are looking for someone who can tell us which purpose to use. Would "keyword" work here? Would it work for all the search entries using getSubmission in the locationbar?
Priority: -- → P1
Whiteboard: [partner-search] → [partner-search][suggestions][fxsearch]
here is the various search features we have in the location bar, we should know which purpose to use for each, even better if we can use the same for all. 1. default text search when text doesn't look like a url. 2. search suggestions 3. search engine aliases 4. reverse parse history search urls (disabled and complicate to do)
for 1-3 I think they can all be the same. That's "keyword" IIRC.
SGTM, 4 is not important right now cause we still don't have a solution to properly implement it.
we are enabling search suggestions in 42 instead of 41... so you won't need to uplift. doing this to include the opt-out bar, bug 959567
sorry - didn't mean to needinfo you Mike - just to add that info on timing. removed the tracking-41+ flag.
Awesome. Still need to fix it. And remove the footgun. :)
Is this still in progress?
we need this soon, we aim to enable the feature in Aurora 42 as soon as critical P1s are fixed.
Argh, ok, lost sight of this bug. tl;dr "getSubmission always needs to have an argument for purpose" I believe from memory that this is triggered by one of the two calls in urlbarBindings.xml. they should change (query) to (query, null, "keyword") and this all magically fixes itself. I'm about to hop a plane or I'd attach a patch.
No worries, we can uplift the fix tpo Aurora, just wanted to notify we may want it in the next couple weeks.
I'm stealing this, if you don't mind, should be trivial and no reason to delay.
Assignee: mconnor → mak77
Status: NEW → ASSIGNED
Comment on attachment 8657187 [details] [diff] [review] patch v1 Approval Request Comment [Feature/regressing bug #]: search suggestions in the awesomebar [User impact if declined]: we need this to build proper stats about searches executed from the awesome bar [Describe test coverage new/current, TreeHerder]: Nightly [Risks and why]: no risk, very trivial change [String/UUID change made/needed]: none
Attachment #8657187 - Flags: approval-mozilla-aurora?
Attachment #8657187 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified as fixed using Firefox 42 beta 1 and latest Aurora 43.0a2 2015-09-23 under Win 7 64-bit and Mac OS X 10.9.5.
You need to log in before you can comment on or make changes to this bug.