176037 - Typeahead skips second letter when match not found

Status: RESOLVED WORKSFORME

(SeaMonkey :: Find In Page, defect, P3)

Description

[Akkana Peck]

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?

Comment 1

[Aaron Leventhal]

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.

Comment 2

[Akkana Peck]

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?)

Comment 3

[Aaron Leventhal]

Attachment: Keep track of last bad char, and use in status string.

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

Comment 4

[Aaron Leventhal]

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

Comment 5

[Jeremy M. Dolan]

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

Comment 6

[Aaron Leventhal]

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

Comment 7

[Kyle Yuan]

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

r=kyle

Comment 8

[Jeremy M. Dolan]

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.

Comment 9

[Akkana Peck]

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).

Comment 10

[Jeremy M. Dolan]

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)

Comment 11

[Aaron Leventhal]

Attachment: Fixes what Akkana found [Checkin: Comment 14]

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 12

[Akkana Peck]

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 13

[Alec Flett]

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.

Comment 14

[Aaron Leventhal]

checked in

Comment 15

[Aaron Leventhal]

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

Comment 16

[Jeremy M. Dolan]

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.

Comment 17

[sairuh (rarely reading bugmail)]

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?

Comment 18

[sairuh (rarely reading bugmail)]

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

Comment 19

[Jeremy M. Dolan]

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

Comment 20

[sairuh (rarely reading bugmail)]

reopening per comments 17 - 19.

Comment 21

[Asa Dotzler [:asa]]

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

Comment 22

[Simon Fraser [no longer active]]

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.

Comment 23

[Asa Dotzler [:asa]]

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

Comment 24

[Aaron Leventhal]

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

Comment 25

[Mike Connor [:mconnor]]

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.

Comment 26

[Simon Fraser [no longer active]]

(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?

Comment 27

[Mike Connor [:mconnor]]

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

Comment 28

[Tony Mechelynck [:tonymec]]

Resetting Assignee per comment #24

Comment 29

[Tobias Fischer]

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.

Comment 30

[Philip Chee]

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.