267885 - Find Toolbar can fall behind typing

Status: RESOLVED DUPLICATE of bug 293889

(Toolkit :: Find Toolbar, defect)

Description

[Jesse Ruderman]

Several users have complained in #firefox that on slow machines (in the 300 MHz
range), the Find toolbar often falls behind what they are typing.  They either
demand the Find Dialog back, ask for an extension to get the Find Dialog back,
or refuse to upgrade.

It should be possible to fix this problem without getting rid of FAYT.  FAYT
should react immediately when the user types another character.  It should then
restart the search (or change and continue the search, if a letter was added at
the end).  Currently, it doesn't react at all, and the Find Toolbar can fall
behind what the user is typing as a result.

I don't know how to reproduce this bug on a fast computer.

Comment 1

[Dylan]

Seconded.  Happens on my 500mhz k6 while trying to use the find toolbar browsing
the java api docs.  I would prefer to use the find dialog regardless if this is
fixed or not, however, and still run .9.1 on my faster machine.

Comment 2

[Aaron Leventhal]

Perhaps whenever there is a keystroke even the current find loop could break
early and add the new key to the current find string before starting again. That
should allow it to keep up.

Comment 3

[Jo Hermans]

*** Bug 272742 has been marked as a duplicate of this bug. ***

Comment 4

[Jo Hermans]

*** Bug 320237 has been marked as a duplicate of this bug. ***

Comment 5

[Cameron McCormack (:heycam)]

Agreed, it is slow on my machine (is only a few years old) when I'm searching in the HTML5 spec (which is quite a long document).  It's especially noticeable when what I'm searching for isn't found.

For example if I type Ctrl+F A B C D E F, and the document has the string "abc" in it but not "abcd", then for every character I type after the "d" there's a big delay before that character appears in the text box.  It's annoying because I will have typed ahead a number of characters and it takes a while for the Find bar to catch up.  This specific issue could be solved by keeping a boolean of whether the last search succeeded, and if it didn't, and the new search has the old search as a prefix (you just typed another character on the end), then it should know without searching that it won't be found.  The flag would have to be cleared if the document is mutated.

Comment 7

[Heewa]

I see this on an 8 core Mac Pro with 2gb memory. I had problems on a 50mb text file (logs from a bug on bugzilla). As I started typing the search text, each keystroke took multiple seconds before letting me type more.

It sounds like the toolbar's text entry needs to be decoupled from the search backend. Let users type however fast they can, and send messages to a separate search thread; if there happens to be a search currently going on, cancel it and start a new one.

Comment 8

[Stephanie Daugherty [:sdaugherty]]

Same problem as 293889, duping to the newer bug as it has more detail.