Closed Bug 1030982 Opened 10 years ago Closed 9 years ago

`browser.search` prefs make is difficult to diagnose search state of the browser

Categories

(Firefox :: Search, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1029148

People

(Reporter: glind, Unassigned)

Details

Attachments

(3 files)

Changing the behaviour of some of the search prefs could make it easier to diagnose diverted users. Bill has observed users with `browser.search.defaultenginename` = <various things> but Google in the search box. I think this can happen when antivirus cleans out side loaded OpenSearch files, but doesn't change the pref back. == Current behaviours: `browser.search.defaultenginename` -> if set to a bad value (where there is not aliased / registered engine), continues using default search. `browser.search.selectedengine` -> if user is using their default, this is empty. == Proposed: a. `browser.search.selectedengine` -> always reflect current engine, even when default is used. b. Unclear about what to do about the 'bad engine' thing. == Why this matters - If FHR starts recording the `browser.search.defaultenginename`, it will wildly over-estimate diversion. - Makes it harder to build something like 'Dr. Firefox'.
We're already making different changes in bug 1029148
1. How will that one be exposed to users? For UserTesting, we can explain "go to about:config, look at this value, tell us what it is". 2. Horizon on the other one might be longer. If FHR starts recording current *soon*, then this solution (while impermanent) prevents some problems with the stats.
(In reply to Gregg Lind (User Research - Test Pilot) from comment #0) > Bill has observed users with `browser.search.defaultenginename` = <various > things> but Google in the search box. I think this can happen when > antivirus cleans out side loaded OpenSearch files, but doesn't change the > pref back. This shouldn't be possible in recent versions of Firefox, we keep the defaultenginename and selectedEngine prefs synced. Need more information on what you're seeing exactly here for this to be actionable.
Group: mozilla-employee-confidential
Attached image defaultenginemismatch2.png (deleted) —
I've attached 3 screenshots from testing where there is a mismatch between browser.search.defaultenginename and the selected default search engine in the search box. All of these users were using Firefox 30. Let me know what additional information you need in order to move forward. I can follow up with participants about the path to this outcome.
Attached image defaultenginemismatch1.png (deleted) —
Attached image defaultenginemismatch3.png (deleted) —
To repro: 1. `about:config` 2. edit browser.search.selectedengine to a garbage value. 3. DONE (Selecting a real engine in the search dropdown fixes this, as expected) As I said in the original report, I don't know what to do about this. It's also superceded perhaps by #1029148. It feels like the true search engine in use should be reflected (read-only) SOMEWHERE ACCURATELY, for use by studies, and FHR and various other things. "Nothing or impossible" -> default seems like a not-awesome.
(In reply to Gregg Lind (User Research - Test Pilot) from comment #7) > It feels like the true search engine in use should be reflected (read-only) > SOMEWHERE ACCURATELY, for use by studies, and FHR and various other things. > "Nothing or impossible" -> default seems like a not-awesome. The result of Services.search.currentEngine is that thing.
How can users see that? Or is it something that can only be seen from some Cu priv'd place. If not, maybe I should open a bug to make that visible.
Users can look at their search box or about:home (and soon about:newtab) to see their selected engine. It's the same everywhere.
Not clear what's actionable here. As Matt says, the the selected search engine is controlled by the search service, and that search engine is what appears in the search bar. We could add the current engine name to about:support if that somehow helps?
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #11) > Not clear what's actionable here. Indeed, let's close this, and open new clean bugs if changes should be made.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: