Firefox does not allow users to change the default search engine, unless the search bar is present

[Robert Jordens]

Binary package hint: firefox

Steps to reproduce (on Ubuntu Lucid):

1. Start with a clean Firefox profile

2. Notice the default search provider is Yahoo in the search box (just to the right of the address bar)

3. Select some text on a page, right click on the selection and notice the item "Search Yahoo for <YourText>"

4. Set the search provider to Google in the search box from the drop-down menu

5. Select some text on a page, right click on the selection and notice the item "Search Google for <YourText>"

6. Go to View -> Toolbars -> Customize and drag the search box out of the toolbar into the customization window

7. Select some text on a page, right click on the selection and notice the item "Search Yahoo for <YourText>" (should be Google still)

8. Go to View -> Toolbars -> Customize and drag the search box into your toolbar, to the right of the address bar

9. Notice Google is selected as default search provider

10. Select some text on a page, right click on the selection and notice the item "Search Google for <YourText>"

This is due to Firefox using the user-set engine when the search bar is present, but using the default engine (which cannot be changed by the user), when the search bar is removed.

Confirmed on:
Ubuntu 10.04 (Firefox 3.6)
Ubuntu 9.10 (Firefox 3.7)
Windows Vista (Firefox 3.6)

ProblemType: Bug
Architecture: amd64
Date: Tue Feb 23 14:40:42 2010
DistroRelease: Ubuntu 10.04
EcryptfsInUse: Yes
FirefoxPackages:
 firefox 3.6+nobinonly-0ubuntu5
 firefox-gnome-support 3.6+nobinonly-0ubuntu5
 firefox-branding 3.6+nobinonly-0ubuntu5
 abroswer N/A
 abrowser-branding N/A
Package: firefox 3.6+nobinonly-0ubuntu5
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-13.18-generic
SourcePackage: firefox
Uname: Linux 2.6.32-13-generic x86_64

[Ria-klaassen (ria-klaassen)]

See Bug 331075.

[Bzbarsky (bzbarsky)]

This seems like a pretty serious usability regression. Is there a reason we're ignoring the user's prefs like this?

[Gavin Sharp (gavin-sharp)]

(In reply to comment #2)
> This seems like a pretty serious usability regression. Is there a reason we're
> ignoring the user's prefs like this?

There is no user pref for "engine to use with the search bar hidden". There is a user pref for "selected engine in the search bar", and a hidden "default engine" pref. It was decided when this was changed that using the "default engine" is better than using the engine that was last selected when the search bar was visible. The plan was to include some way of setting the "default engine". I'm not sure that just using the current engine would solve any of the problems: that would mean people who had hidden the search bar using 1.5 will be "stuck" with the last-selected engine when they upgrade to Firefox 2, and it won't necessarily be obvious for them that to select a new engine they need to unhide the search bar.

This is a front-end change that was made on both the 1.8 branch and trunk, so I'm not sure what relevance the blocking1.9a1? flag has. I think this should block Firefox 2.

[Mike Connor (mconnor)]

So, the rationale here is that hiding the searchbar means that you're getting rid of the multiple search functionality, so the default engine is probably the best bet (as opposed to whatever you had last before you got rid of the searchbar).

Options are:
1) Reimplement the dialog
2) Remove the menuitem/disable the keyboard shortcut when the searchbar is hidden
3) Expose a means to make an engine the default in the search manager.

I'd go with 3, myself, but I'm not married to any particular solution.

[Kakadu+bugzilla (kakadu+bugzilla)]

If the Search Engine Manager is transferred into the Add-ons Manager (where it could fit quite nicely IMO), then this becomes moot, as the user would then have two ways to access the configuration dialog to change their selected engine.

But mconnor's suggestion to reimplement the dialog is also a good one, and to be honest I don't think it was a good idea to remove it in the first place.

[Gavin Sharp (gavin-sharp)]

I don't see how moving the search engine manager has anything to do with this, since it doesn't currently expose a way to select a new "default" engine.

[Mike Connor (mconnor)]

I think we're going to go with #3, and also use that setting to control the context menu search, since that has the same issues, plus a couple of additional once.

[Adam Guthrie (ispiked)]

*** Bug 338997 has been marked as a duplicate of this bug. ***

[Pkasting (pkasting)]

While it may be nice to provide a way for users to change their default engine even when they've removed their search box, I still don't see why we can't have the default engine be initially set to whatever the user last set in their search box. That's at least more likely to be what they want than some arbitrary default we provide that they haven't set at all.

In other words, I think there should be one variable holding the current/default search engine, and both the search box and the alternate UI we implement (for when the search box is absent) should change it. That means I disagree with what Gavin says in comment #3 "was decided when this was changed". Is there a particular bug, set of use cases, etc. that made us decide this? I can't see what use case would benefit from this behavior, whereas I can think of several that benefit from my proposed behavior. (The key, of course, is that when the user has NOT hidden their search box, the "default search engine" pref is basically irrelevant, as selecting Tools->Web Search just takes you to your search box. If Tools->Web Search always used your "default engine" then I think the split prefs would make more sense.)

BTW, where is the "search manager" where this new UI can be exposed?

[Mike Connor (mconnor)]

(In reply to comment #9)
> While it may be nice to provide a way for users to change their default engine
> even when they've removed their search box, I still don't see why we can't have
> the default engine be initially set to whatever the user last set in their
> search box. That's at least more likely to be what they want than some
> arbitrary default we provide that they haven't set at all.

Its more likely, but can also be spectacularly wrong. It also means that if you searched with Amazon last, you need to change the searchbar in order to context search with Google. This was the concern that led us to switch from the current engine to the default engine. It was incredibly annoying, to be honest.

> BTW, where is the "search manager" where this new UI can be exposed?

Its in the engine selection dropdown.

[Pkasting (pkasting)]

(In reply to comment #10)
> (In reply to comment #9)
> > That's at least more likely to be what they want than some
> > arbitrary default we provide that they haven't set at all.
>
> Its more likely, but can also be spectacularly wrong. It also means that if
> you searched with Amazon last, you need to change the searchbar in order to
> context search with Google. This was the concern that led us to switch from
> the current engine to the default engine. It was incredibly annoying, to be
> honest.

That doesn't seem *more* spectacularly wrong than if the default is something you didn't want to use for anything. I completely accept that it won't be right in cases, but I don't see why the default we give is ever going to be "less bad" in some way.

I also don't really see how switching the context search engine with the dropdown is hideous. That's what my trunk install seems to do for me right now. Do we really think we can provide awesome UI for someone who wants to use one search engine in the search box but a different for context searching, at the same time?

> > BTW, where is the "search manager" where this new UI can be exposed?
>
> Its in the engine selection dropdown.

Ah... well, how will that be helpful in this case then? The case where we're expecting people to use it is the case where they've removed their search box, so they can't get at the manager.

If our answer is "they should have changed it before removing/they can re-add the bar", well, then they could re-add the bar to just switch the drop-down search engine too, so it doesn't seem like the manager would be an improvement, unless you've already accepted that having two different prefs is necessarily better. Even then it's still clunky to switch this.

If we must do separate prefs, it seems like we should set the "default" to the empty string, which means it should use the search box' last-used engine. If someone then changes the default to something non-empty, context-search and Tools->Web Search always use this. This allows people to set a different context search than their dropdown if that really ticks them off, while still doing a best-guess behavior for other users. In that case I'm not sure I would expose any UI to change the "default" beyond about:config; if we also must expose UI, then something accessible from (at least) the prefs window a la:
Web searches from outside the search box should always use:
(o) The engine I last selected in the search box
( ) This engine: | Google |v|
This would at least be modifiable when the user had removed their search box.

[Mike Connor (mconnor)]

pushing out non-critical-path bugs to b2

[Mike Connor (mconnor)]

At this point, doesn't look like this is going to happen for Fx2. This is only a change in the Ctrl-K case, so we're not going to hold on this.

Will take a patch if one appears soon enough.

[Joey Minta (jminta)]

Created an attachment (id=230808)
work in progress

Work in progress. I'm really struggling to wrap my mind around the use-case here, just because it's so foreign from anything I'd personally do. If someone wants to take a look at the approach here and let me know if it's close to correct, I'd appreciate it.

Note that this patch hasn't undergone *any* testing yet, so most likely it will completely fail to function. I'm just looking for code-writing feedback.

[Pkasting (pkasting)]

(In reply to comment #14)
> Created an attachment (id=230808) [edit]
> work in progress

For clarity, is what you're implementing the last paragraph of comment 11? That's sort of what the patch looked like, but I didn't actually try using it.

[Joey Minta (jminta)]

(In reply to comment #15)
> (In reply to comment #14)
> > Created an attachment (id=230808) [edit]
> > work in progress
>
> For clarity, is what you're implementing the last paragraph of comment 11?
> That's sort of what the patch looked like, but I didn't actually try using it.
>
The last paragraph of comment #11 has too many 'if' clauses in it for me to respond with a simple 'yes' or 'no.' What we're doing here is:
a.) A 'Default' button that users can set in the search-engine manager. This will set the userDefaultEngine attribute to that engine. Normally, userDefaultEngine points to defaultEngine.
b.) When the user does things like context-menu search, or serching from Tools without the search box visible, we'll now get userDefaultEngine instead.

My biggest concern here is that it's nearly impossible to describe what this 'default' button does in any concise form. I think it's just going to confuse users.

The above plan was largely based off of comment #4, but I still think the drawback of that proposal is that we don't make it clear to the user what they're choosing. I'd really like to get some more feedback from the user-experience folks here.

[Pkasting (pkasting)]

(In reply to comment #16)
> The last paragraph of comment #11 has too many 'if' clauses in it for me to
> respond with a simple 'yes' or 'no.'

My excerpt of it would be "set the 'default' to the empty string, which means it should use the search box' last-used engine. If someone then changes the default to something non-empty, context-search and Tools->Web Search always use this."

[Joey Minta (jminta)]

(In reply to comment #17)
> My excerpt of it would be "set the 'default' to the empty string, which means
> it should use the search box' last-used engine. If someone then changes the
> default to something non-empty, context-search and Tools->Web Search always use
> this."
>
Then the answer is 'almost'. We use the defaultEngine, as defined by the app, rather than the last selected one.

[Pkasting (pkasting)]

(In reply to comment #18)
> Then the answer is 'almost'. We use the defaultEngine, as defined by the app,
> rather than the last selected one.

Is the default used for anything else? Why would it be better to have a userDefault and a Default if, when they differed, the default was not used anywhere?

[Gavin Sharp (gavin-sharp)]

(In reply to comment #19)
> Is the default used for anything else? Why would it be better to have a
> userDefault and a Default if, when they differed, the default was not used
> anywhere?

nsIBrowserSearchService's defaultEngine is used to determine which engine to select in a clean profile, for the context menu search when the search bar is hidden, and for the "Tools->Web Search" action when the search bar is hidden.

Joey's patch changes all uses other than the "which engine to select on startup with a new profile" case.

[Pkasting (pkasting)]

(In reply to comment #20)
> Joey's patch changes all uses other than the "which engine to select on startup
> with a new profile" case.

In that case, it seems like it would be better to not add a userDefault alongside the default, but just to have us ship with something (Google) as the default like we do now, and make the UI "set default" just change the default directly instead of the userDefault.

[Kliu (kliu)]

What about changing the default engine every time the user changes what the topmost engine is in the search engine order? I think that's a fairly intuitive way for the user to say "I prefer engine foo over engine bar".

(I suggest this because someone on the mZ forum just posted about this problem and complained about how the default engine didn't change despite his re-arrangement of the search order.)

The upside to this is that this could be done with very minimal (read: zero) UI/string changes, is somewhat intuitive, and would (I think) be fairly low-risk for this late in the Fx3 game.

[Kliu (kliu)]

Created an attachment (id=315999)
set topmost engine as default

Very simple patch to implement my suggestion in comment 22

[Gavin Sharp (gavin-sharp)]

Kai: could you file a new bug for that proposed workaround? I don't want it getting confused with the original intent of this bug.

(Note about the patch: we should probably turn nsIBrowserSearchService's defaultEngine into a settable property, and let it handle setting the pref accordingly.)

[Kliu (kliu)]

(From update of attachment 315999)
Filed the workaround as bug 429513.

[Michal Suchanek (hramrach)]

Currently in FF3 I get

1) the search in the search box which is quite sane

2) context search (ie select a word in text, right click, "Search with X for word" is in the menu)
 - X is the search engine selected in the search box - not sure this is the best thing to do but at leas controllable somehow

3) search in the location bar (ie when I mistype an URL)

- always Google, no pref UI for this to be found except perhas something in about:config

 - very bad

 - probably a regression since Mozilla - it had an UI pref pane for search

[Hskupin (hskupin)]

Joey, you wanna still be the assignee?

[Robert Jordens (jordens)]

Binary package hint: firefox

steps to reproduce:

* start a clean new firefox profile
* notice the default search provider is yahoo in the search box
* select some text on a page, right click on the selection and notice the item "search yahoo for YourText"
* set the search provider to google in the search box
* select some text on a page, right click on the selection and notice the item "search google for YourText"
* go to view-toolbars-customize and drag the search box out of the toolbar
* select some text on a page, right click on the selection and notice the item "search yahoo for YourText" (i'd expect google here)
* go to view-toolbars-customize and drag the search box into your toolbar
* notice google is selected as default search provider
* select some text on a page, right click on the selection and notice the item "search google for YourText"

ProblemType: Bug
Architecture: amd64
Date: Tue Feb 23 14:40:42 2010
DistroRelease: Ubuntu 10.04
EcryptfsInUse: Yes
FirefoxPackages:
 firefox 3.6+nobinonly-0ubuntu5
 firefox-gnome-support 3.6+nobinonly-0ubuntu5
 firefox-branding 3.6+nobinonly-0ubuntu5
 abroswer N/A
 abrowser-branding N/A
Package: firefox 3.6+nobinonly-0ubuntu5
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-13.18-generic
SourcePackage: firefox
Uname: Linux 2.6.32-13-generic x86_64

[Draycen DeCator (ddecator)]

This also occurs with Firefox 3.7 on Ubuntu Karmic (only in this case, Google is the default). Marking this bug 'Confirmed' until we can determine how to file this report. Thanks for reporting this bug, and please feel free to report any more problems you encounter!

[Draycen DeCator (ddecator)]

This bug has recently been reported downstream on Launchpad (https://bugs.launchpad.net/firefox/+bug/526453)

The tested systems include: Ubuntu 10.04, Ubuntu 9.10, and Windows Vista

This problem still occurs on Firefox 3.6 as well as Firefox 3.7

I have linked this report with the downstream report.

[Draycen DeCator (ddecator)]

I also confirmed this bug using Firefox 3.6 on Windows Vista. This implies that the problem is upstream, so I will search the Mozilla Bug Tracking System to see if it has been reported yet.

[Draycen DeCator (ddecator)]

I have linked this bug to an upstream report for the same bug. While this bug is similar to bug 310217 on Launchpad, I have not marked it as a duplicate or linked it to the same upstream bug due to the fact that Mozilla seems to be keeping the upstream bugs separate, so the downstream bugs will be better separate to avoid confusion. Thank you again for bringing this to our attention, and please continue to file any bugs that you encounter!

[Mitch Towner (kermiac)]

Set to Triaged/Low at the request of Draycen DeCator.

[Julien Wajsberg (felash)]

In Aurora (version of 5 dec 2011) I have still the same problem.

I really don't care of whatever default is set on a new profile. All I want is a way to set it easily and error-free from an UI.

Right now, we have to change the pref browser.search.defaultenginename in about:config, and if we set it to an unknown value (like "bing" instead of "Bing"), the default search is broken. This is wrong.

I feel using the current selected search engine is not a good option here: there's really no point at having a search bar if we do this. If my last search was on ebay, amazon or wikipedia, I don't want to have my default search to go there, I want my default to go to whatever default is set.

To me, 2 options would be appropriate :
- either: the first search engine of the list is the default
- or: the user can set it using a "set default" button. Then take care to put a sensible default if this search engine is gone. This could also be done for any option, when "browser.search.defaultenginename" is set to a wrong value. Another bug maybe ?

Either way, make it apparent in the UI, like make it bold with (default) after its name.

And I can think of a third solution :

- replace the empty keyword values by a null/undefined value which would be written as "none". Then, the real empty ("") would be for the default search. It makes sense because, really, that is what seems to happen. But from the user point of view it's maybe difficult to understand.

Thanks

[Gavin Sharp (gavin-sharp)]

*** Bug 776153 has been marked as a duplicate of this bug. ***

[Gavin Sharp (gavin-sharp)]

*** Bug 782559 has been marked as a duplicate of this bug. ***

[Manuel-spam (manuel-spam)]

I think "First one is default" is a reasonable idea...

If someone, who can decide about such changes, agrees to that, I could try to create a patch...

[Mike Conley (mconley)]

*** Bug 239752 has been marked as a duplicate of this bug. ***

[From-bugzilla2 (from-bugzilla2)]

(In reply to Manuel Reimer from comment #32)
> I think "First one is default" is a reasonable idea...
>
> If someone, who can decide about such changes, agrees to that, I could try
> to create a patch...

I can see the idea that the most used entry would probably do fine at the top... I'm just not sure it's a strong enough association to justify constraining users' ability to choose the menu ordering they want.

Perhaps more important, an explicit "set default" button would be more intuitive than just expecting users to understand that the first one listed is the one which will appear in context menus and other "only show one engine" places and more elegant than providing a help message in the dialog to explain it.

[Gavin Sharp (gavin-sharp)]

We're going to add some preferences UI for selecting a default engine in bug 738818.

[Lsblakk (lsblakk)]

relnoted as part of "Firefox search touchpoints have been consolidated behind a single search default preference. Switching to a different search in the search box will now change the setting for the addressbar search and the context search for selected content. "

[ashughes (anthony-s-hughes)]

Adding this to the sign-off criteria for Firefox 23.0b1.

[Ioana-budnar (ioana-budnar)]

Verified as fixed on Firefox 23 and 24. More details in bug 738818, comments 126 to 129.

[Paul White (paulw2u)]

Upstream bug report closed "VERIFIED FIXED", see comment #44
Closing by marking "Fix Released"