Now that bug 1301315 is in, it's time to have the larger discussion of allowing the "isDefault" parameter so that engines can be set as the default. We have a number of partners (search engine partners) where setting a search engine as the default is a major point of their extensions (DuckDuckGo, Qwant, Yahoo, etc.). My general take on this is that any usage of chrome_settings_overrrides should be tagged for some level of review to verify that there is no hijacking going on. I'm not sure what we should do for the unlisted side of things. There's also a question of if users should be notified in this situation Chrome presents a dialog that says "Is this the search page you were expecting" after the first search and allows you to reset (which actually disables the extension). But if the AMO listing makes it clear it changes the search engine, how necessary is this?

Kev, I need you to weigh in on this one.

My input (I am working with some of Yahoo's extensions) is that it would be great to have the possibility to use dynamic variables in the manifest.json. Chrome is currently supporting the following search_url in the manifest.json: "search_url": "https://__MSG_search_domain__/__MSG_search_path__?p={searchTerms}&fr=staticvalue1&type=staticvalue2" It supports internationalization, which is great for having multiple languages using different domains. But except for internationalization, it only supports {searchTerms} which is a key only used by Chrome. It doesn't let us have dynamic values for "fr" and "type". What we would hope for is that "fr" and "type" could be dynamic. In short, it would be great to have such kind of capability: "search_url": "https://__MSG_search_domain__/__MSG_search_path__?p={searchTerms}&fr={frParam}&type={typeParam}" where {frParam} and {typeParam} are variables that can be initialized during install. Thanks! Francois

I'm a bit colored here, as we will use the API to provide our search as default search, but I agree with Mike that the extra popup Chrome shows ("Is this the search page you were expecting") feels redundant, as this is already covered by accepting the extension's permissions and might confuse users.

I know this is a very important and difficult decision, but do you have any ETA on when this decision on supporting default search will be made? We received a mail that if we don't move to the new API until the first of September we loose our featured status. But without default search there is sadly no reasonable way for us to migrate, and first of September isn't that far away anymore (especially expecting some time for testing and QA and also the time until the new browser version would be rolled out).

As this is a very important topic to us and as we have been told this at the moment is mostly a management decision not really a technical issue, we tried to come up with a compromise so that legitimate extensions are still able to change the default search, but preventing fraudulent extensions from doing changes that the user doesn't want: We could imagine that Firefox ignores the “is_default” option for all extensions except the ones that have been manually whitelisted by a reviewer from the Firefox team. Maybe Mozilla could even limit this whitelisting option only to featured extensions like DuckDuckGo (https://addons.mozilla.org/de/firefox/addon/duckduckgo-ssl/) and Ecosia (https://addons.mozilla.org/de/firefox/addon/ecosia-the-green-search/)? Sorry for spamming this bug ticket so much, but this is very important to us, our users and the millions of trees they help plant.

> Sorry for spamming this bug ticket so much, but this is very important to us, our users and the millions of trees they help plant. Do you believe your users would be unwilling to go through the steps to make your search engine the default to support your cause? Current steps are: 1. Click magnifying glass. 2. Right click on Ecosia. 3. Select "Set As Default Search Engine"

I obviously don't have any valid data on this, but extrapolating from similar problems in the past I'd guess that would mean at the very least a 50% decrease in successful switches (and I feel this is a rather positive estimate). Installing the extension already is a three step process (clicking button, clicking allow, clicking install), adding another three steps to this process makes a total of 6, which is really a lot for a user to do this one simple thing they already want. Additionally, big parts of our user base are really non-technical people, which makes it hard to communicate this process, especially in multiple languages and for all supported operating system. What are the arguments against providing this option (especially for specifically whitelisted extensions)? Is this something people complain about a lot in Chromium/Chrome (they have this options for a while now, so I imagine there is valuable data to be had)?

> What are the arguments against providing this option (especially for specifically whitelisted extensions)? Is this something people complain about a lot in Chromium/Chrome (they have this options for a while now, so I imagine there is valuable data to be had)? It's something people complain about in Firefox a lot (see support.mozilla.org.) Google has the ability make sure that if you change the search engine, you own the domain you are changing it to; we do not. So they don't have as much of an issue. We're investigating other possibilities, but most likely anything we provide will be opt-in for the user.

(In reply to Mike Kaply [:mkaply] from comment #8) > > What are the arguments against providing this option (especially for specifically whitelisted extensions)? Is this something people complain about a lot in Chromium/Chrome (they have this options for a while now, so I imagine there is valuable data to be had)? > > It's something people complain about in Firefox a lot (see > support.mozilla.org.) > > Google has the ability make sure that if you change the search engine, you > own the domain you are changing it to; we do not. So they don't have as much > of an issue. > > We're investigating other possibilities, but most likely anything we provide > will be opt-in for the user. Thanks for getting back to me and providing the support link. A search for "search" shows that it seems there is roughly as many people having trouble changing the search to something non-default as there are people having trouble with changing back to the default. From the first two pages: Want to go away from default: * https://support.mozilla.org/en-US/questions/1164666 * https://support.mozilla.org/en-US/questions/1159629 * https://support.mozilla.org/en-US/questions/1157211 * https://support.mozilla.org/en-US/questions/1170310 Wanting to go back to default: * https://support.mozilla.org/en-US/questions/1159868 * https://support.mozilla.org/en-US/questions/1164299 So it seems the current setup where extensions can change the default search seems to work quite okay on average, except maybe for "antivirus" software. Isn't this something that could maybe be addressed by only allowing listed extensions to change the default search? You mention that Chrome verifies ownership of a site. Wouldn't that be a viable option for Firefox, too? It sounds like a great compromise. If you would need any support with implementing such a feature in Firefox, we could of course try and help with that (although our resources are more in go/js than they are in c++/rust). As I tried to illustrate in my post above, having another step (like an opt-in) is very likely to decrease successful switches substantially, so if you can find any other option that would help us and our users tremendously.

Mike, is something like to land for 57 for this bug?

Yes, I would really like to get this in 57 if at all possible.

OK, so I thought this was a different bug. We're doing is_default work in a separate bug. I'm duping this.