Currently, Firefox's awesomebar isn't so awesome at handling a bunch of different kinds of inputs that are almost certainly intended to be search queries. Examples: Input: bacon Expected outcome: searches for bacon while performing background host lookup for bacon Actual outcome: first performs host look up for bacon, which (almost always) fails, falling back to a search for bacon On some ISPs/networks, doing the DNS lookup first can take several seconds, making us much slower than other browsers for the common case. :( Input: 84/2 Expected outcome: searches for 84/2, returning Google's built-in calculator result of 42. Actual outcome: Firefox takes forever (several minutes) trying to reach http://84/2, until finally it fails and returns an error page. :( Input: (1+sqrt(5))/2 Expected outcome: searches for (1+sqrt(5))/2, returning Google's built-in calculator result of 1.61803399. Actual outcome: searches for (1+sqrt(5)), returning 3.23606798. Input: (1.+sqrt(5))/2 Expected outcome: searches for (1.+sqrt(5))/2, returning Google's built-in calculator result of 1.61803399. Actual outcome: Firefox tries to find http://www.%281.+sqrt%285%29%29/2 and returns server not found. I wrote a front-end patch to fix some of this stuff specifically for the URL bar, but Gavin prefers that we just fix up the fixup code in docshell/. From a maintainability perspective, I agree. Time for me to write C++, I guess.

I guess, at first, fixup's expected result would be "bacon" -> "http://www.bacon.com/" but this functionality is not working very well; That is bug 40082.

I posted this under bug 595148, but maybe this is a more appropriate place. It seems that other browsers (IE, Chrome, Opera) handle this by requiring either the protocol (ex. http:) or trailing slash before doing a hostname lookup. In the above examples, "bacon" would always assumed to be a search unless it also has the protocol (http:bacon) or trailing slash (bacon/). I don't see why the other cases couldn't be handled the same way (ex. requiring http:84/2 or 84/2/ before looking up 84 as a host). Please forgive me if I am providing inappropriate information or providing it in the wrong place, but I just wanted to get involved with issue because it is one of my peeves with Firefox right now. I am not currently involved in development and I am new to posting here. I wouldn't mind helping with code, but I need to know how to get started. I think this sums up my suggestion at a high level. I'm going to (attempt to) use regexps for these examples: Input: ^([^:]*:)(.*)$ (string contains the ":" character near the beginning) Result: If \1 is a known protocol, handle the complete input string as a URI. If \1 is not a known protocol, either search for \1\2 in the default search engine or suggest http:\2. This choice is probably arbitrary or based on a preference Input: ^([^:]*/)$ (string does not contain ":" but has a trailing "/") Result: Handle http://\1 as a URI. Input: ^([^:]*[^/])$ (string does not contain ":" or trailing "/") Result: If \1 is a keyword, do a keyword search, else do a search for \1 using the default search engine. If the input string is a URI that includes a username, I think this logic requires the input string to have the protocol specified. So "un:pw@host" would lookup un: as a protocol. You would have to specify at least "http:un:pw@host" to have "un" treated as the username. I think that is probably okay, especially since this seems to be the current behavior (lookup "un:" as a protocol). I think the point of this is to determine whether to do a search or to handle the string as a URI, so I'm not getting into the particulars of what "handle as URI" means. I assume there must be existing code for that. I hope this makes sense.

I would simply drop the DNS query as a method to determine whether the text is a search term or a URL and rely exclusively on the content of the text. Advantages of this are: (1) Some DNS do "DNS hijacking", which consists on replacing the usual NXDOMAIN message on a failed query with a custom search page. As a result, entering "bacon" in the URL box would go to http://bacon, which is a valid server according to the DNS, rather than searching with the user's engine of choice. If "bacon" is recognized as a keyword by the browser, the DNS lookup is skipped and this problem is solved. (This could also be solved by changing to a DNS that doesn't do this stupid thing, such as Google or OpenNIC) (2) As Frank Yan pointed out, some DNS may take too long to reply. This would speed up the search process, although not much since the search engine URL should be looked up anyway unless it's cached. (This could also be solved by changing to a DNS that isn't that slow) (3) The browser would immediately be able to immediately know whether the text is a search term or a URL, and could give feedback to the user of what will happen when they hit enter. This could be a suggestion similar to the one obtained when a keyword for a "search site" bookmark is used, like "Search bacon with Google", and could additionally offer options for using other search engines without having to change the selected search engine on the search bar. A problem is that the machine may be connected to a LAN in which e.g. "intranet" is a valid domain name, but entering "intranet" in the URL bar would search that term in the search engine instead. For those cases, I would just suggest using "http://intranet" instead. Similarly, if the user wants to search "vb.net" in the search engine rather than going to http://vb.net, he could prefix it with a space, "<space>vb.net".

This is a mockup of the behavior I wanted to propose as a visual feedback when the browser is going to interpret the input text as search terms for the search engine.

I just want to add that right now entering "document.open" in the location bar gives me "Server not found" instead of searching for "document.open". Both Safari and Chrome do the right thing here. This is something developers do often, and we should make it work. (In reply to cousteau from comment #3) > I would simply drop the DNS query as a method to determine whether the text > is a search term or a URL and rely exclusively on the content of the text. Note that Chrome does this, and users have switched to Firefox from Chrome over this issue. Something to think about. See https://code.google.com/p/chromium/issues/detail?id=30636.

(In reply to Seth Fowler [:seth] from comment #6) > (In reply to cousteau from comment #3) > > I would simply drop the DNS query as a method to determine whether the text > > is a search term or a URL and rely exclusively on the content of the text. > > Note that Chrome does this, and users have switched to Firefox from Chrome > over this issue. Something to think about. See > https://code.google.com/p/chromium/issues/detail?id=30636. Well, my idea is that URL-looking text such as "example.pre" would be recognized as a URL (because it has a dot), even if the TLD is not known. The problem would be with URLs like "intranet" or "localhost" (with no dots), that would explicitly require prepending http:// (well, maybe "localhost" could be an exception, or there could even be a list of custom exceptions in about:config) > I just want to add that right now entering "document.open" in the location > bar gives me "Server not found" instead of searching for "document.open". > Both Safari and Chrome do the right thing here. This is something developers > do often, and we should make it work. I'm not sure this is "the right thing"; if I enter an invalid URL I'd rather get a "URL not valid" than a search page. My idea is that these searches would be indicated as a search by prepending a space, so that " document.open" would NOT be recognized as a URL but as a search. Maybe an intermediate solution would be to add a 'Search "document.open" in the web' link to the "server not found" page (although that would involve an extra click).

Hi, Appreciate the work being done on this but in version 29 this is still an issue. Single word search in the location bar is still extremely slow. "apple" does not take you to apple.com, despite the intended functionality. It brings up Google search with a search on apple after a very long wait. My DNS is not that slow that it explains the delay. Single word key searches are more common then we might think. Regular users of Firefox only experience a lag which they can't explain since the browser does not make it clear to the user what it is trying to do for him/her. An option would not be such a bad idea. I know I would appreciate it. Regards

Really,this is unaceptable. I opened this bug a while ago, (not noticing it was a duplicate) https://bugzilla.mozilla.org/show_bug.cgi?id=926140 And there I do an important comment: The user experience of someone switching from Google Chrome to Firefox is heavily affected by this bug. In google chrome you time anything in the location bar and a google search popups almost instantly. In firefox you have to wait for seconds. A real stopper.

* time => type (sorry)

I have to agree with Tito and Laurens here. I have used Chrome for years because of seamless integration with my Nexus 4 and the various Google Apps I use, but now with Mobile Firefox working well, I've switched back to Firefox for desktop (now v29). Overall I'm very impressed with account/bookmarks handling, rendering, JavaScript performance, etc. But there is one thing I do more often than anything else, and that is search. Maybe Chrome spoiled me, but I like to be able to type a search term into the location bar and get what I want (i.e. search results, unless I add one of the major TLDs at the end). In Firefox I don't get what I want when I search for a single-word term. On a good day, I now wait ~30 seconds on a high-speed university connection for Firefox to determine it needs to search, to contact Google API, and to look up the term. If I search from the search bar or the use a multi-word term, the results are virtually instantaneous. Disabling browser.fixup and has not helped. In fact, I agree with others that the DNS lookup function is a poor default because many residential ISP DNSs hijack the domain lookup into a spammy, ad-laden search under the ISP logo. As for progress: things seem to be getting worse. The changeover from Chrome to Firefox has just this one jarring and frustrating phenomenon to make me want to return to Chrome. tl;dr: +1 for an overhaul of the feature as a high priority for UX.

jordanharp: A possible workaround could be to set up a keyword for Google: Click the search engine icon on the search bar > "Manage search engines" > select Google and click "Edit keyword" > set "g" as the keyword. Now when you type "g mozilla" in the URL bar it'll be as if you typed "mozilla" in the search bar and searched with Google. This doesn't really solve the problem and implies that you remember to type the "g" each time, but can come in handy for quickly searching on different sites. I have that configured for Google (g), Wikipedia (w), YouTube (yt), Google Images (im), Wolfram Alpha (=), Linguee (l), and a few other sites, and once you get used to it it's very practical.

This might be useful : https://github.com/niklasb/vimium/blob/fuzzy/lib/completion.js

Cool stuff! You can also preface search queries with ? to tell Firefox to skip the DNS lookup and use your default search engine. That said, let's help the Firefox engineering team do their jobs by not cluttering this thread with "me too" responses. If you'd like to show your support for a solution to this problem, you can use the "vote" link at the top of this page. If you'd like to discuss workarounds or share tips, the community support forum at https://support.mozilla.org/en-US/kb/get-community-support is a great place for that. Thanks!

In Firefox Aurora (33.0a2), single-word queries from the location bar seem to be just as fast as those from the search box. Has this bug been fixed? If so, thanks very much! :)

Yes, most of this bug has been fixed, but the case of "(1.+sqrt(5))/2" has not been. I'll file a separate bug for that since it doesn't need all the background that this bug has.

See bug 722435 for the decimal-included case.