sayrer noticed that every keypress on a Gmail search field was generating a console warning about an inefficient query. There are a few things going on here, but the interesting part for this bug is that each invocation off form history's AutoCompleteSearch() had a null previousResult, so a new query was being performed. Looks like something is broken, we should be getting an empty (but non-null!) previousResult so that we don't his the DB with each keystroke. nsIAutoCompleteResult seems to have some support for a RESULT_NOMATCH result, but who knows if this old code is working.

This bug may have been copied from XPFE: // check the many criteria for failure if (aStatus == Components.interfaces.nsIAutoCompleteStatus.failed || aStatus == Components.interfaces.nsIAutoCompleteStatus.ignored || aStatus == Components.interfaces.nsIAutoCompleteStatus.noMatch || aResults == null || aResults.items.Count() == 0 || aResults.searchString != this.currentSearchString) { this.mLastResults[aSessionName] = null; Thus forgetting that we "succesfully" found zero results.

This is the equivalent toolkit code in nsAutoCompleteController.cpp: PRUint16 searchResult; result->GetSearchResult(&searchResult); if (searchResult != nsIAutoCompleteResult::RESULT_SUCCESS && searchResult != nsIAutoCompleteResult::RESULT_SUCCESS_ONGOING) result = nsnull;

The lines causing this behavior are in nsAutoCompleteController.cpp where results would be cleared if there were no matches from the previous search: 257 if (mRowCount == 0) 258 // XXX Handle the case where we have no results because of an ignored prefix. 259 // This is just a hack. I have no idea what I'm doing. Hewitt, fix this the right 260 // way when you get a chance. -dwh 261 ClearResults(); I will properly fix (what I believe is) the "ignored prefix" issue in bug 497541 which will fix this.

Fixed in bug 497541 on trunk: http://hg.mozilla.org/mozilla-central/rev/47bfcd275ede