This is related to bug 700470, which is a wholly back-end fix. 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. Example 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. :( Fixing this requires both changing nsIURIFixup to determine inputs to be search queries more aggressively and for it to provide something that front-end code can listen to in order to generate a notification upon successful host lookup for those unqualified hostnames. I'm not sure what the front-end/back-end split will be exactly, but I'll put this down as Firefox: Location Bar for now. Gavin, how would we architect this, so that other front-ends built on Gecko will also still be able to use unqualified hostnames when the lookup is moved to the background?

This is actually a Snappy bug. Inheriting priority from bug 700470. I'm unassigning myself, because a front-end fix for this has been deemed unacceptable, so invasively modifying nsIURIFixup would be required.

This bug alone has swayed many Firefox users to switch. I want to like Firefox. Help me out.