New issue
Advanced search Search tips
Starred by 61 users
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
Do not auto add detected search engine into Chrome's search engines list
Reported by, Dec 28 2010 Back to list
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

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.
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?
Labels: -Area-Undefined Feature-Omnibox Feature-Search
Status: Untriaged
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
 Issue 51141  has been merged into this issue.
 Issue 65588  has been merged into this issue.
 Issue 130696  has been merged into this issue.
Project Member Comment 22 by, Mar 11 2013
Labels: -Feature-Omnibox -Feature-Search Cr-UI-Browser-Omnibox Cr-UI-Browser-Search
Sign in to add a comment