393244 - occasionally hitting enter in the url bar will not have an effect

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[(not reading, please use [e-mail] instead)]

occasionally hitting enter in the url bar will not have an effect.

I have run into this issue before, and I thought I had addressed it (see bug #389593 comment #14).

but I just hit it again when typing "g test" and hitting enter.  (in my profile, g is a keyword search for http://www.google.com/search?hl=en&q=%s)

what's going on is we call EnterMatch(), and our status is nsIAutoCompleteController::STATUS_SEARCHING, we will bail out and handle the enter the next time we process a result.

the next time we get into ProcessResult(), if enter was hit and searches are ongoing, we will stop the searches and then call PostSearchCleanup(), which will then handle the enter.

using the almighty printf, I can see that when this happens we never call ProcessResult() after EnterMatch(), so we will never call PostSearchCleanup() which will call EnterMatch() again.

I believe the reason this is happening is that the search timer has been cleared, and so it will not fire and call StartSearch()

note, this is a regression due to bug #389593.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: patch

in StopSearch(), if we were searching, call PostSearchCleanup() which will handle any pending enter and will set mSearchStatus properly (based on row count)

Comment 2

[(not reading, please use [e-mail] instead)]

turns out, this isn't so "occasional", as Gavin tells me:

<gavin|> I hit it mostly when entering "bug XXXXXX" and hitting enter
<gavin|> "bug" is a bookmark keyword I have
<gavin|> perhaps I hit it a lot in that case because of my large bugzilla history?

Gavin and I did some debugging it is the call to stopSearch() from the popuphiding handler (http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/autocomplete.xml#780).

when that happened, if you had a search ongoing, we'd stop the search, but because StopSearch() did not call PostSearchCleanup(), we would not reset mSearchStatus properly.

then, on the next enter, because we thought we were still searching, we'd delay the handling of enter until ProcessResult(), but that would never happen, as the search was stopped.

Comment 3

[(not reading, please use [e-mail] instead)]

fixed.

Checking in toolkit/components/autocomplete/src/nsAutoCompleteController.cpp;
/cvsroot/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cp
p,v  <--  nsAutoCompleteController.cpp
new revision: 1.64; previous revision: 1.63
done

thanks again, Gavin!

Comment 4

[Bob Uliss]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0

still FIXED in RC1

Comment 5

[José Jeria]

Bug 376084 seems to be the same issue and is getting a lots of duplicates lately (after 3.0).

Comment 6

[Marcia Knous [:marcia]]

https://litmus.mozilla.org/show_test.cgi?id=7668 added to Litmus.