New issue
Advanced search Search tips
Starred by 63 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2012
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Issue 68177: Do not auto add detected search engine into Chrome's search engines list

Reported by, Dec 28 2010

Issue description

Chrome Version       : 10.0.612.3
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 3.x: OK
       IE 7/8: OK

What steps will reproduce the problem?
1. Visit a search engine site (e.g.:, whose search url can be detected by Chrome.
2. Search any words in that site.
3. Chrome will auto add search engine url into Chrome's search engines list

What is the expected result?
Prompt for users to decide whether to add detected search engine URL into Chrome's search engines list, instead of AUTO addition.

What happens instead?
Chrome will auto add any detected search engine URL into Chrome's search engines list as a search engine candidate.

Please provide any additional information below. Attach a screenshot if

Comment 1 by, Oct 4 2011

This is frustrating because there is no way to purge the list of search engines *except* the ones you've manually added. After some browsing, the list becomes full with dozens of entries (100-200), and ctrl-F doesn't work in the view. All I want to do is edit the two search engines I've manually added, but I have all these junk engines I do not care about in my view, so cannot find them. In terms of privacy, I also would prefer not having to worry about yet *another* cache which I cannot empty without destroying my manually-added search engines.

Comment 2 by, Dec 21 2011

This is important; some people simply don't want any other search engines than the ones they add themselves. Making an option/flag to disable this behaviour does not seem too hard.

Comment 3 by, Feb 28 2012

Hey, why no developer has given it a patch for so long?

Comment 4 by, Mar 3 2012

Labels: -Area-Undefined Feature-Omnibox Feature-Search
Status: Untriaged

Comment 5 by, Mar 3 2012

Status: WontFix
The engines are sorted, so it shouldn't be prohibitively hard to find an engine, and you can one-click delete engines.

We don't intend to provide additional configurability beyond this.

Comment 6 by, Mar 3 2012

That it isn't hard to find an engine is a bug, not a feature, because it creates a privacy issue. Even if one cleans history, search engines remain and since most sites nowadays offer search feature, good part of history can be tracked this way. Also, you're suggesting a troublesome resolution, as user has to delete engines at the end of every browser session, since Chromium does not remember which engine was deleted and, when user visits site again, Chromium adds it.

All this would be resolved with a simple flag to disable automatic search engine additions. Why you "don't intend" to provide it since users clearly want it? That's beyond me.

Comment 7 by, Mar 3 2012

Being able to clear search engines from the Clear Browsing Data dialog is IMO an important point, but that's covered by bug 87685.

We don't provide all kinds of options and features users have asked for.  That's how we keep Chrome from having pages upon pages of options and becoming bloated with things most people don't care about.  The tradeoff is, sometimes one of those things we don't provide is something you actually wanted.

Comment 8 by Deleted ...@, Apr 4 2012

This is a very annoying problem for me, every time I visit our company wiki at http://wiki, it adds it to the search engines. Now every time I type "wiki Charles Darwin" (for example) into the chrome address bar, it tries to search my company wiki, rather than doing a google search for the terms and having the wikipedia page at the top as expected.

Comment 9 by, Apr 4 2012

If you frequently visit an intranet page but don't ever want to use it as an omnibox search engine, the workaround is to change the search engine name to something like "iwillneverusethissearchengine" rather than deleting the search engine.  It's a little inconvenient, but it's also a relatively rare case to have inconvenient intranet search engines AFAIK.

Comment 10 by, Apr 26 2012

Please reconsider. 

Ā«Simple one-click deletionĀ» of the 50-100 search engines that are stuffed into the otherwise neat, clean and well kept list of the search engines can be frustrating.

Comment 11 by, Apr 26 2012

Filing a different bug to redesign the search engine management dialog to allow for easy mass-deletion of engines, a la gmail's mass-email deletion capabilities, seems reasonable to me.

Comment 12 by Deleted ...@, Aug 15 2012

Well, this needs to be addressed.
If it's bloat adding an option for this, then what is having hundreds of search engines automatically added? Search Engines you probably won't use. R

Remove the auto add feature and have it so users can add engines manually, that way you get the best of two worlds.

Comment 13 by, Sep 10 2012

I agree, this would be pretty useful for *power users* and does not seem to be so hard to implement. Simply provide a check box to enable/disable the *auto add*.

Comment 14 Deleted

Comment 15 by, Sep 28 2012

This issue isn't just drawing a line between too many preferences and more user control; it's inconsistency when drawing that line. The search engine manager already lets you add custom search engines and manipulate auto-added searches. The designer is saying that there are plenty of users that need to add searches and can comprehend a box with "URL with %s in place of query" but that the time/convenience cost or of a toggle for automatically adding searches would be too much complexity for users. I think that this perplexing inconsistency is why this issue is still debated and extremely frustrating for so many users.

Comment 16 by, Oct 4 2012

There should either be a toggle to enable/disable auto-adding of search engines, or at the very least allow people to shift-select the auto-added search engines and delete them in bulk.

Comment 17 by, Oct 4 2012

It occurs to me that the whole explanation for not having the ability to disable this "feature" because of bloat is inconsistent bs. Along these lines, it can be easily argued that the whole automatic search add can be considered a bloat. There should be a switch precisely to avoid the bloat caused by this unnecessary and inconvenient "feature".

Now, I don't think Chromium developers are not smart enough to see it, but I start to think that Google may somehow benefit from users having log of every searchable site they ever used. I can't see anything that would explain such a stance, taken without any attempt to solve the problem.

Comment 18 by, Oct 4 2012

Labels: Restrict-AddIssueComment-Commit
The bug tracker is a work planner for developers, not a debate forum.  Arguing with a decision here rarely makes us more likely to reverse course.

We've explained elsewhere the many reasons why we don't add options in general (see e.g. item number 6).  This is not a unique case; we refuse to add options all the time.

Also, considering Google doesn't log the search engines you have stored locally, I don't see what rationale would explain the conspiracy theory in comment 17.

There are legitimate issues raised on this bug like "I should be able to clear these with other browsing data" (bug 87685).  In our view these don't rise to the level where adding search engines to begin with is so catastrophic that we should add a giant abort switch to short-circuit the process altogether.  In general we do want people to feel that they have control over what their browser is doing, but that only goes so far; we don't provide (for example) an options-menu checkbox to disable disk caching or a table where you can list different user agents you want to send to particular sites or a toggle between Firefox-style and IE-style GIF animation timings.  There are a million things we could conceivably add options for, and the individual harm of a single one of them is small, but the cumulative harm is large; it's death by a thousand papercuts.

In general, the route we prefer to go for niche cases is to try and support them via extensions.  We would probably not be opposed to an extension API to control the search engine database if there were clear and compelling use cases for it ("delete all my engines" alone would not be enough).

But for the core request here, no, we're not going to add it into the product.

Comment 19 by, Dec 4 2012

 Issue 51141  has been merged into this issue.

Comment 20 by, Dec 4 2012

 Issue 65588  has been merged into this issue.

Comment 21 by, Dec 4 2012

 Issue 130696  has been merged into this issue.

Comment 22 by, Mar 11 2013

Project Member
Labels: -Feature-Omnibox -Feature-Search Cr-UI-Browser-Omnibox Cr-UI-Browser-Search

Sign in to add a comment