179218 - Replacing bad character with next typed character prevents type ahead find from returning useful negative search result

Status: VERIFIED DUPLICATE of bug 176037

(SeaMonkey :: Find In Page, defect)

Description

[Tuukka Tolvanen (sp3000)]

linux, trunk cvs 2002-11-08

Steps:
  - go to http://www.cs.hut.fi/Opinnot/T-93.210/2002/suomi.html
  - type /xdraw

Scenario 1:  |Text not found: "daw"|     "da" highlighted on page.
Scenario 2:  |Type ahead find stopped.|  Nothing highlighted.
Scenario 3:  |Text not found: "x"|       Nothing highlighted.
Scenario 4:  |Text not found: "xdraw"|   Nothing highlighted.

Questions:
 a) Did I make a typo?
 b) Does the string "xdraw" occur on the page?
 c) Does it appear likely that I made a typo, whether or not I did?

1 is what typeaheadfind does now. 2 is what it would do as such if the bad
character replacing were removed, due to the mashing solution (bug 166993). 3
is just one random way to handle this. 4 is what emacs does.

Issues:
  * After a failing search for a string, where the search progress was not
    carefully observed after each typed character, typeaheadfind fails to
    convey any useful information about why the search failed (a, b).
  * Typeaheadfind feedback often makes me feel liek my keyborad is wonky nad
    im tyeping wewy badly (c).

Related: bug 168408 comment 0, bug 166993, bug 176037 comment 16

Comment 1

[Tuukka Tolvanen (sp3000)]

Hmm, looks like this was partly fixed in bug 176037, so it works more like
scenario 2 instead if the first character was found...?

Comment 2

[Alexander Opitz]

What is the state of this bug?

Comment 3

[Daniel Roberge]

I get the same Scenario 1 as the original reporter on Linux build 2003111005.
This does look like a duplicate of bug 176037 though.

Comment 4

[Mathew McBride]

Can confirm on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031230

Comment 5

[Asa Dotzler [:asa]]

*** This bug has been marked as a duplicate of 176037 ***