The default bug view has changed. See this FAQ.

Firefox 23 ignores keyword.URL setting




4 years ago
4 years ago


(Reporter: Igor Mackeev, Unassigned)


23 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)



(1 attachment)



4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20130517 Firefox/23.0 (Nightly/Aurora)
Build ID: 20130517004016

Steps to reproduce:

My keyword.URL setting is as follows:
This means that wherever I am I will always receive results on EN-US Google pages after entering my request in the address bar.

Actual results:

Aurora 23 ignores the above setting and throws me to the local page (the country I am at now).

Expected results:

Aurora should have honored my settings.


4 years ago
Blocks: 738818

Comment 1

4 years ago
keyword.URL has been removed from FF23+.
Component: Untriaged → Search
Yes, that was an intentional change. Keyword searches now use the URL from the currently selected engine. To adjust the URL used for keyword searches specifically, you can create a custom OpenSearch plugin per, and use the "application/x-moz-keywordsearch" URL type.
Last Resolved: 4 years ago
Resolution: --- → INVALID


4 years ago
Duplicate of this bug: 890201

Comment 4

4 years ago
Awesome, guys.
I could use only keyboard to search in firefox 22, but I can't do it now.

Comment 5

4 years ago
I'd like to have location bar, context menu, and about:home searches use the same engine, and have that be controlled by a single pref (to be configured in the preferences dialog).

I failed to find such preference in Options.

Comment 6

4 years ago
Like a lot of people I am using Keyword.URL to set a different search engine for the URL bar than the search bar. Because it simply doesn't make sense to have 2 search fields where you can query the same search engine. Please don't be such Fuckers and lets find a normal solution instead of removing features. What about checking for keyword.URL in the settings and use its value if its customized and in the normal case the search engine settings from the search bar is used?!

Comment 7

4 years ago
It's already possible to run a search with various search engines in the location bar, just read the FAQ:

Comment 8

4 years ago
@Loic that has nothing to do with the problem. We want two bars, the urlbar with startpage and the searchbar with wikipedia as search engine for example.

Comment 9

4 years ago
keyword.URL was subject to be hijacked by some programs (like adwares/badwares) to force the user to use an unwanted search engine.
In addition, the trend goes to the unification between the location bar and the search bar.

Comment 10

4 years ago
But can't be that easily changed like keyword.Url?


4 years ago
Duplicate of this bug: 903708


4 years ago
Duplicate of this bug: 905635


4 years ago
Summary: Aurora 23 ignores keyword.URL setting → Firefox 23 ignores keyword.URL setting

Comment 13

4 years ago
Created attachment 792118 [details]
an add-on that restores keword.url's usability
Duplicate of this bug: 906299

Comment 15

4 years ago
Re #9, may I perhaps ask how?

One of the most useful features in Firefox (to me) is that:

(1) Ctrl-L + "string without spaces"  => go to URL
(2) Ctrl-L + "string with spaces"     => Google for that string
(3) Ctrl-K + "string"                 => Wikipedia search.

For now, the "keyword.URL hack!" extension is a good workaround.

[Incidentally, I have seen Firefox systems where (2) is broken by an addon toolbar, but as the user deliberately installed that, I don't think this is Firefox's problem; furthermore, the toolbar addon's search hijacking has not been successfully neutered by the change in Fx 23]

Comment 16

4 years ago
"For now, the "keyword.URL hack!" extension is a good workaround."
If we need a workaround, why is this ticket closed as invalid?

Comment 17

4 years ago
Is Mozilla saying that there is no way to include this functionality securely in Firefox? I am very skeptical of that declaration if so. 

If I'm reading it correctly, Mozilla is saying, "The way we implemented this functionality in the past was vulnerable to hijacking so we eliminated the functionality." If that's the case: why? Why not look for a secure, safe way to implement it?
No, that's not what "Mozilla" is saying. I've explained the reasoning behind this on firefox-dev: (see bottom of the post)

If you'd like additional clarification on the motivation or reasoning, I recommend you post there, rather than in Bugzilla.

Comment 19

4 years ago
I don't get it, only because it's now called instead of keyword.Url it cant be hijacked anymore? is controllable by users, keyword.URL wasn't. Please read my firefox-dev post.

Comment 21

4 years ago
I read your post, but it was not that clear that the stupidity of your costumers is really the reason for this change ... so there is no way to add another icon or button whichs handles the keyword.URL settings, like the drop down of the search bar?
Yes, of course there was a way to do that. But because the use case was deemed uncommon enough to burden our UI with, we decided against doing that in Firefox proper, and stuck with a simpler interaction model that addressed the majority of cases.

Thankfully, because Firefox has awesome add-on APIs, that use case was able to be addressed by add-ons. Which it really quickly was!

Comment 23

4 years ago
"Controllable by users" meaning having an exposed prefs UI, rather than about:config? I read the post you linked, Gavin, and maybe I'm missing something, but I don't see an explanation there of what the security vulnerability was. "... that we have evidence was being widely abused" isn't an explanation. 

Has anybody explained anywhere how keyword.URL is/was vulnerable to attack in a way that other prefs aren't? And does this abuse risk still applie to people who are using keyword.URL via the hack extension?

Comment 24

4 years ago
(In reply to :Gavin Sharp (use for email) from comment #20)
> is controllable by users, keyword.URL wasn't.
> Please read my firefox-dev post.

But that explanation makes no sense. You're basically saying, "keyword.URL didn't have a user-visible UI. So instead of adding one, we just removed it." Why not just add one? Put it in preferences, Or put an icon next to the "star" icon for changing it (this could open a dropdown that simply has a checkbox to make it the same as the search box or to use one of the other search providers in the user's list). Simple.

Comment 25

4 years ago
Can we have an example for such hijacking addon or code?
keyword.URL is not any more vulnerable than other prefs, there's just more value in setting it. Redirecting user searches and e.g. adding your referral code or pointing to a site that hosts your ads is a quick and easy way to gain revenue.

The evidence that it was abused comes from several places:
- Telemetry data that suggested that on the order of 40% of users on the release channel had a customized value of this preference, despite it never being exposed. The data can be found on, in the "Telemetry Histogram" section, by searching for the FX_KEYWORD_URL_USERSET measure and changing the channel to "release" (apologies for the slow/unlinkable UI)
- Collated evidence from feedback mechanisms like (see e.g. and many more) and
- Evidence from collected add-ons that actually set the preference, and don't reset it on uninstall. These add-ons are not all malicious (some are), but because setting the pref was an "easy" way to change searches, some were not careful to reset it properly on uninstall.

As I've already explained in this bug, we originally planned to add separate UI to control keyword.URL (or its equivalent), but we decided that it was simpler conceptually to just consolidate search settings, since most people use just one search engine. The progression and reasoning here is all visible in bug 738818.

Comment 27

4 years ago
(In reply to :Gavin Sharp (use for email) from comment #26)
> - Telemetry data that suggested that on the order of 40% of users on the
> release channel had a customized value of this preference, despite it never
> being exposed.
I think that this may be because when the old behavior ("Google Organic Search", i.e. go directly to a website or search Google depending on the relevance of the first result) was replaced with always showing a Google search page, many users disliked this change and set the old behavior back.
Instructions for doing so were in many places, and "Type about:config, click ok, search keyword.URL and replace it with blah.blah/blah" is very easy to do, even for non-power users.  In fact, I think this was the first time I used about:config.
Maybe a more meaningful result would be to check whether keyword.URL was set to something other than a "common" search engine (Google, DDG, Bing, etc)

> keyword.URL is not any more vulnerable than other prefs, there's just more
> value in setting it.
Well, in that case, maybe renaming the property to keywordsearch.URL would be enough to confuse malware :)  (at least until they realize and adapt to newer Firefox versions)


4 years ago
Duplicate of this bug: 919519

Comment 29

4 years ago
A changed keyword.URL doesn't mean malicious changes. I know quite a lot of people and companies who didn't like the Google search engine (especially after the revelation of PRISM) and change it's default search engine, or just edit the url to add url parameters for localized search results.

I appreciate the motivation to make browser search options more transparent to Firefox users but removing functionality is a work-around for another problem: the malicious change of (for ordinary users inaccessible) browser options. Making UI improvements, like selecting a search engine for the "keyword search" and "about:home" options more easy for ordinary user would have been a better solution (IMHO).

The addon "Keyword Search" uses that approach. I hope it will be implemented in the normal Firefox configuration options soon.


4 years ago
Duplicate of this bug: 931566
You need to log in before you can comment on or make changes to this bug.