STR: 1. Open awesomebar 2. Type in some search term that also matches some history entries (see screenshot) 3. Hit the magnifying glass search icon on the keyboard (I'm using the Galaxy Nexus with stock keyboard) Expected results: - Does a search for the search term using the default search engine Actual results: - Keyboard hides and awesomebar goes away, but no search is performed. In my case I was on about:home before pulling up the awesome bar and I ended up back on about:home If you type in a search term that doesn't match any history entries (such that "Google/Search for <term>" is the top result in the awesome screen) then hitting the magnifying glass button does the expected search

Brian, will your new search suggestion work affect this? Maybe fix it? ;)

This happens when searching a number, regardless of whether the item is in the history. I confirmed this behavior with kats. (In reply to Margaret Leibovic [:margaret] from comment #1) > Brian, will your new search suggestion work affect this? Maybe fix it? ;) Nope, I don't think bug 586885 will fix this.

Requesting tracking on this bug. I keep running into it (although sometimes by accident) and it's kind of annoying.

(In reply to Kartikaya Gupta (:kats) from comment #3) > Requesting tracking on this bug. I keep running into it (although sometimes > by accident) and it's kind of annoying. This hasn't been called out as a major pain point by our users and doesn't appear to be a regression from 14.0(.1). Therefore, no need to track for a specific release. I'll nominate for Fennec tracking, which I know Mark/Brad are using for targeted version on the engineering side. The tracking list is meant for critical release issues.

When the user doesn't choose a search suggestion, we pass what was entered along to gecko, and it eventually goes through browser.loadURIWithFlags. This is actually a dupe of a core bug 693808.