Closed Bug 179218 Opened 20 years ago Closed 19 years ago
Replacing bad character with next typed character prevents type ahead find from returning useful negative search result
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
Hmm, looks like this was partly fixed in bug 176037, so it works more like scenario 2 instead if the first character was found...?
What is the state of this bug?
I get the same Scenario 1 as the original reporter on Linux build 2003111005. This does look like a duplicate of bug 176037 though.
Can confirm on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031230
*** This bug has been marked as a duplicate of 176037 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.