Reproducible on the latest Beta (BuildID: 20130206083616): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 Reproducible on the latest Aurora (BuildID: 20130207042017): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20130207 Firefox/20.0 Reproducible on the latest Nightly (BuildID: 20130207030936): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130207 Firefox/21.0 Steps to reproduce: 1. Launch Firefox. 2. Go to about:config, type keyword.URL in the search bar and hit Enter. 3. Double click on this preference, and type in the edit box: evilsearch.com or www.evilsearch.com. Click OK. 4. Open a new tab, type in the awesomebar one or more words to search for, and hit Enter. Expected results: A notification should appear under the awesomebar, asking: Firefox is using 'evilsearch.com' or 'www.evilsearch.com' for searches from the location bar. Would you like to restore the default search (Google)? Actual results: No notification showing. Note: 1. This issue is not a regression: it reproduces back to Nightly 19.0a1, BuildID: 20121107045842.

So what's happening here is that when keyword.URL is not a valid URI, the backend nsDefaultURIFixup code just bails out and fails to trigger a load entirely: http://hg.mozilla.org/mozilla-central/annotate/469333ea459c/docshell/base/nsDefaultURIFixup.cpp#l350 It could instead notify defaultURIFixup-using-keyword-pref with a null URI, and KeywordURLResetPrompter.jsm's prompt function could handle that case specially by having a different prompt. Or actually, maybe it would be best to just always reset the pref in that case, since it isn't serving a useful purpose (keyword search from the location bar is broken entirely).

I don't think we need to track this. It shouldn't affect many users, and for those that it does, there's no change from the status quo.

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #2) > I don't think we need to track this. It shouldn't affect many users, and for > those that it does, there's no change from the status quo. Agreed. After reproducing the issue locally to better understand the user experience, I have no idea why an adware developer would want to change keyword.URL to a malformed (and therefore non-loading) URL.

We're going to end up just removing keyword.URL from Firefox entirely in bug 738818, so it's not worth fixing this.