Closed Bug 176037 Opened 20 years ago Closed 12 years ago

Typeahead skips second letter when match not found

Categories

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

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla1.3alpha

People

(Reporter: akkzilla, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: [no l10n impact])

Attachments

(1 file, 1 obsolete file)

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?)
Blocks: isearch
Severity: normal → minor
Status: NEW → ASSIGNED
OS: Linux → All
Priority: -- → P3
Hardware: PC → All
Target Milestone: --- → mozilla1.3alpha
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
Attachment #104179 - Flags: review+
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=?
Attachment #104179 - Attachment is obsolete: true
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.
Attachment #104777 - Flags: review+
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.
Attachment #104777 - Flags: superreview+
checked in
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** 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.
Component: Keyboard: Navigation → Keyboard: Find as you Type
reopening per comments 17 - 19.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 179218 has been marked as a duplicate of this bug. ***
Keywords: helpwanted
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.
Severity: minor → normal
Flags: blocking1.8b4?
Whiteboard: [no l10n impact]
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.
Flags: blocking1.8b4? → blocking1.8b4-
(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.
Product: Core → SeaMonkey
QA Contact: bugzilla → keyboard.fayt
Resetting Assignee per comment #24
Assignee: aaronleventhal → nobody
Attachment #104777 - Attachment description: Fixes what Akkana found → Fixes what Akkana found [Checkin: Comment 14]
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.
Status: REOPENED → RESOLVED
Closed: 20 years ago12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.