Load a page, e.g. http://www.mozilla.org/start/ Pick a string where the first letter will be found but the second won't be, e.g. "dns". Quickly type the three letters. It beeps, and in the status bar it says "ds not found". What happened to the n?

That's the way it works. This allows the user to type the correct character after the incorrect one, without hitting backspace. However, hitting backspace and then the correct letter will also work. So, if I'm looking for fish, I could type fiqsh or fiq backspace sh Maybe we should fix the status bar message though.

As a user, I find it very confusing. I typed abc, and the status bar says ac not found. That's not what I typed! By the time I hear the beeping I've often typed several more characters. Seems like for three or four, the status bar will show all but the second character; for five or more, it just says "Type ahead find stopped." (stopped? why?)

This keeps track of the last bad char. Bad chars can be automatically removed by an algorithm that allows but eliminates the need for Backspace after a bad char. It inserts the bad char back in the right place in the string after 2 successive bad chars, so that the status message appears correct. Seeking r=akkana

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

The behavior described in comment 3 still sounds very confusing. Users understand backspace. There's absolutely no need to attempt magic.

I disagree. I've seen firsthand that some users don't want to have to hit backspace.

Comment on attachment 104179 [details] [diff] [review] Keep track of last bad char, and use in status string. r=kyle

Then there's no predictable outcome when typing at a normal pace. This is absolutely terrible. Again--no other apps search work like this. They keep adding characters even if there is no match. Perhaps I want to finish typing the word, then ctrl-g in another window and see if it's in that once, since it's not here. At the very least a pref is required, as much as I hate prefs. Current behavior is intolerable.

I tried the patch: I went to a mozilla.org page and searched for "newage" (partial match, Newsgroups). The status line string said: Link not found: "newage". Great! Then I hit ESC and accel-G; now it says: Link not found: "newag". Why does it drop the last character for accel-G searches? Bringing up the find dialog also has the string "newag". I tend to agree with Jeremy about it not being predictable if it does something different for two bad chars than for one, but I'm willing to try it and see. Usually when I hit this I type more than two bad characters anyway, because I type the whole word I'm looking for as quickly as I can (because I've been conditioned that if I don't type quickly it times out and I have to start over).

The timeout Akkana slyly complains about is also an issue. Can't we remove it, and have escape, scrolling (arrows, pg up/down), mouse action (click, scroll, menus), and similar things cancel out of the search? If we make it too short, we frustrate users by canceling searches they were in the middle of typing. If we make it long enough to avoid doing that, it's too long to wait for anyway, so it may as well not exist. (Sorry to turn this bug into a discussion of all things typeaheadfind)

Thanks for catching that Akkana. I want to try this. If it becomes impossible to balance the needs of the fast typists with the poke and look typists, then we'll have to revisit the decision or see if the problems can be fixed. Akkana, can you r=?

Comment on attachment 104777 [details] [diff] [review] Fixes what Akkana found [Checkin: Comment 14] Wow, what a lot of special cases. But if that's what you think most users will want, I guess we should at least try it. It gives a compile warning: nsTypeAheadFind.cpp: In method `nsTypeAheadFind::nsTypeAheadFind ()': nsTypeAheadFind.h:205: warning: member initializers for `PRUnichar nsTypeAheadFind::mLastBadChar' nsTypeAheadFind.h:203: warning: and `PRInt32 nsTypeAheadFind::mRepeatingMode' nsTypeAheadFind.cpp:151: warning: will be re-ordered to match declaration order The warning goes away if you put mLastBadChar(0) last in the nsTypeAheadFind::nsTypeAheadFind() definition. Fix that, and r=akkana. It does fix the problems I saw earlier, and seems to work for my use pattern as well as the users it's designed for.

Comment on attachment 104777 [details] [diff] [review] Fixes what Akkana found [Checkin: Comment 14] thank goodness. This was driving me crazy! I'd like to see the warnings fixed as akkana describes.. sr=alecf with the warnings fixed and/or akkana's review.

checked in

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

Fix works as well as possible. Backspace always works as expected, and if there's only one unmatched character, it's typed over. The only problem this leaves is: if I'm searching for the word "function", and I type "fu" and then the 'n' is an error, I may end up highlighting a very different word as TAF will then try to search for "fuc". This could end up scrolling (irrevesibly! -- there's no way to get back to your previous position in a very long document) to content you don't care about. I think I would still like a hidden preferance down the road for mozilla's TAF to work like Vim's "incremental search", in that respect.

this seems to work...most of the time. however, i found another case where this still seems to be a problem: try searching for link with "from" in it. trying it out on this page would suffice. the status bar says, 'Link not found: "fom"' --what happend to the "r"? should this be reopened? or, am i encountering a different issue?

forgot to mention: tested using 2002.11.19 comm trunk bits on win2k, linux rh7.2 and mac 10.2.2.

sairuh: this is caused by the same thing as my comment 16.

reopening per comments 17 - 19.

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

The behavior is still broken. Using the steps in comment 1, searching for 'dns' now matches 'ds' in the second heading. That's just wrong.

Aaron, are you going to have any time to look into this for the upcomging Aviary releases? If not, any ideas on who could?

No, that's why it says "helpwanted". I don't deal with typeahead/fayt bugs anymore.

not a b4 blocker, if SeaMonkey wants it, they can fix it, since we have a forked impl that doesn't and won't support this type of finding.

(In reply to comment #25) > not a b4 blocker, if SeaMonkey wants it, they can fix it, since we have a forked > impl that doesn't and won't support this type of finding. What is this forked impl of which you speak?

Toolkit's find as you type implementation, which firefox uses, is separate and doesn't match this behaviour.

Resetting Assignee per comment #24

Is this Bug still valid? Since Bug 345526 was fixed, and SeaMonkey-Trunk implements the Toolkit-FAYT, I think this was solved too on Trunk/1.9.1-Branch. Using the SeaMonkey 2.0b1, I can't reproduce this Bug. When I search a not existing string, all typed characters were displaed in the statusbar, no character was skiped.

WFM Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110305 Firefox/4.0b13pre SeaMonkey/2.1b3pre These days we use the toolkit FAYT. And default to the Findbar.