The code at http://lxr.mozilla.org/mozilla/source/browser/base/content/browser.js#2797 currently pulls in the *browser's* default search engine, and uses that to load a webpage for Tools > Web Search when the bar is hidden (I'm not convinced I like this anyway, but that's a moot point). My browser's default engine, which there is no option anywhere to change, is Google. However, *my* default engine, knowing to the browser as the "current engine" is MSN Search, and that is what's selected in the search drop-down when it is visible. I believe the menu item should absolutely respect this setting and use currentEngine instead of defaultEngine. I'm flagging this as a regression because the old behaviour opened a dialog which would default to the current engine, and now it's not only going to the wrong engine but it's not configurable.

See Bug 331075.

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

(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.

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.

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.

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.

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.

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

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?

(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.

(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.

pushing out non-critical-path bugs to b2

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.

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.

(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.

(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.

(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."

(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.

(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?

(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.

(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.

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.

Very simple patch to implement my suggestion in comment 22

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.)

Comment on attachment 315999 [details] [diff] [review] quick-n-dirty workaround: set topmost engine as default Filed the workaround as bug 429513.

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

Joey, you wanna still be the assignee?

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.

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

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...

(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.

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

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. "

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

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