285930 - Find not working with delete, backspace, cut, paste

Status: RESOLVED WONTFIX

(Toolkit :: Find Toolbar, defect)

Description

[Csaba Gabor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

Incremental search/find (ctrl+f / FAYT) is pretty fast and spiffy.
But it doesn't work as I expect when I use the backspace/delete/cut/paste key or
do an insert:

I expect that if I have typed something into the incremental search field and I
then hit the backspace key (in other words, delete the last character typed)
that find will show me the first occurrence of the new (shorter) word starting
from where the search point started.

For example, consider:
Sebastian, the other day there was this sentence that I saw.

If I bring up incremental find, and type:
t => finds the t of Sebastian
h => finds the th of the
e => finds the the of the
r => finds the ther of other
ctrl+f (currently ctrl+g) => finds the ther of there (see show_bug.cgi?id=285437)
space => finds the 'ther ' of 'other ' (wrapped search)
backspace => finds the ther of other (see note, below)
backspace => finds the the of the
ctrl+a => selects the the in the fast find window
n => finds the n in Sebastian (and not the n in sentence)


This was a small example, and in practise one would expect the found text to be
on different parts of the screen (ie. scrolled).  But chances are, if the user
is changing what s/he is looking for, they are thinking about searching from the
original start point and not about a new search going forward from where they
are (especially when paging is involved).

Note:  in emacs, having done a repeat search (the ctrl+f that found the ther),
if the backspace is used, it does not erase the last letter of the search term.
 Rather, it starts cycling backwords through the prior terms found until it gets
to the first term that was found with that set of letters.  At that point, it
will accept the backspace to delete the last letter and regress the search even
further.
I am somewhat ambivalent on this point and not convinced that it offers real
advantage.

However, I would like to see two possible exit modes: either keep the
page/search point where the search is currently at (as Firefox currently does),
or reset it (and the page view) to where the current search started from (but
keep the most recent term in the FAYT window).


To summarize, I would very much like:
1.  Anytime there is a new word in the (find as you type) FAYT window (regarless
of whether from a character addition, deletion, insertion, cut, paste), the
found word should be the first one from the starting point of this search.

and 2.  Allow an exit method (how about escape or Shift+escape) that reverts the
page and new search point to what it was just as this search was started and
have an exit method (say tab or escape) that exits the page as it currently is
and sets the new search point to the current location.

Nice would be: 3.  If text is selected in the main page (as opposed to the
address bar), pressing ctrl+f should start off the FAYT field with the text of
what is selected.  Hence, the first item found is what is already selected
(however, this could be messy if the user has selected a lot of text or the
entire page).


Csaba Gabor from New York

Note to self: See also show_bug.cgi?id=252371 (finding in textarea)
and show_bug.cgi?id=157788 (hilight all)

Reproducible: Always

Steps to Reproduce:

Comment 1

[Martijn Wargers (dead)]

Isn't this already fixed?

Comment 2

[Martijn Wargers (dead)]

Again, this is still worksforme, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060728 BonEcho/2.0b1
Csaba, you still see this bug?

Comment 3

[Csaba Gabor]

I have Firefox 1.5.0.6 (same version that you indicated), and the behaviour is still the same for me (I have caret browsing turned on) as at the time of the original report.

Specifically,
2: Esc will abort the search leaving the highlight where it is (that's good), but I don't know a way to revert the cursor to where the search was started (Shift+Esc behaves as Esc).

1: Current behaviour is still that searching goes forward from where the current search point is (in other words, I don't see any change from the original reported behaviour).  Thus, if you have searched for 'ther ' and delete that last space with a backspace, the beginning of the search point will not move according to the current logic since 'ther' is a substring of 'ther '.

However, I wish to amend my specification of desired behaviour just slightly.  I have implemented a version of this myself for textareas and kept the behvaiour that Emacs has when the delete key is used at the end of the word (ie. when the delete key is pressed while at the end of the search term, the current entry of the search stack/position is popped, and the previous entry/position of the search stack is used.  This internal search stack is amended whenever a letter is appended to the end of the search term or a repeat search is indicated (via ctrl+g)).

However, if the change to the search entry comes in any other way (in other words: insert/cut/paste/delete of non last character/character typed that is not the final character), then the new search cannot be related to the current stack and hence the current stack is completely removed (except the initial starting point), and a new search started from the original point.  Note that text based Emacs does not have a way of updating the search term in the fashion mentioned in this paragraph.

Comment 4

[Wayne Mery (:wsmwk)]

sorry, but comment 0 and comment 3 are time consuming to follow.
are you asking for emacs-like behavior?

Comment 5

[Wayne Mery (:wsmwk)]

reporter gone, looks like.

Comment 6

[Hugo Heden]

I'd like some discussion on this, so I'll try to clarify in a few comments what the reporter is suggesting. The most obvious special-case of what is said in the original report is this: 

-- Selection should jump backwards if user presses backspace.

Scenario: The user types a search string in the Find-box. As each letter is typed, the selection jumps forward to the first match of the current search string. This is all good.

However, if the user presses backspace to remove the last character in the search string, the browser should jump *back* to the *previous* selection.

Reasoning: The browser should interpret a backspace keypress in this context as the user correcting a mistake (for example a mis-type). So the search should return to the state it had before the user-mistake occured.

Comment 7

[Hugo Heden]

Continuing with the special case:

-- Selection should jump backwards if user presses backspace.

Consider the following little example document.
   
   par

   par

   ptart
   
   park   

   part

   park

   ptart
   

The scenario is this (try it!): The user searches for "park", but accidentally types "part", so the selection jumps to forward to "part". The user then corrects the mistake by pressing backspace, and then adds a 'k' to get "park".

Desired (IMHO) behaviour: When backspace is pressed, the selection jumps back to "par" (actually the *first* occurance of "par", where by "first" we mean the first occurance after the original starting point of the search). When the user presses 'k' the selection jumps to the first occurance of "park".

Actual behaviour: When the user presses backspace, the selection remains on "part". When the user presses 'k', the selection jumps *forward* to the last occurance of "park".

Comment 8

[Hugo Heden]

Continuing with the special case:

-- Selection should jump backwards if user presses backspace.

I hope it is becoming clear that the current behaviour is not ideal. The example in Comment #7 shows that the user can accidentally *miss* a search result just by mistyping a character ('k')-- even though the mistake is immediately corrected (backspace).

Again, the desired behaviour would be to interpret the backspace keypress as a correction of a mistake, so the search should return to exact state it had before the mistake occured.

Comment 9

[Hugo Heden]

*Generalizing* the above reasoning about user typing-mistakes a bit yields the
following:

-- Not only backspace, but *any* "correctional edit" of the search string, should make the selection jump backwards..

(In the expression "correctional edit" here, obviously we do *not* include the
usual appending of characters in find-as-you-type)

[Note: I am not sure I support this part -- perhaps this gets too weird. We
would need to really try this out for a while..]

Anyway, consider the little example text document above again (comment #7).

The scenario this time is almost exactly identical as the one in comment #7
(try it!): 

The user searches for "ptart", but accidentally types "part", so the selection
jumps to forward to "part". The user then corrects the mistake by ... pressing
left arrow to navigate to the beginning of the search string, and inserting a
't'.



(Possibly) desired behaviour: When 't' is inserted (as character number 2 in
the search string), the selection jumps back to "ptart" (the *first* occurance
of "ptart", where by "first" we mean the first occurance after the original
starting point of the search).

Actual behaviour: When 't' is inserted (as character number 2 in the search
string), the selection jumps *forward* to "ptart".

Comment 10

[Hugo Heden]

So what is suggested here is an "extended find-as-you-type" mode of operation. As usual, the mode is entered when the user enters a character within the search box. And as the user appends characters to the search string, the selection jumps forward. 

But now, the original starting point of the search must be remembered. And when user "corrects a mistake" in the search string, the selection jumps backwards in the document.

Now, one question remains: what exactly is "correcting a mistake"? Because any user action that is neither "appending a character" nor "correcting a mistake" is an *exit-condition* for this mode of operation.

Comment 11

[Hugo Heden]

-- What is "correcting a mistake", and what is an find-as-you-type "exit condition"?

o) IMHO, pressing backspace is clearly "correcting a mistake", so the selection should jump to the *first* match after the original search starting point (hence possibly backwards), and find-as-you-type mode should remain in effect.

o) Removing an *arbitrary* character from the search string is possibly "correcting a mistake".

o) *Inserting* a character at an arbitrary location within the search string is possibly "correcting a mistake".

o) But any other user action should *probably* be an exit condition of this
find-as-you-type mode. Examples: The user clicks "Find Next" (or presses
Ctrl-G). The user presses escape. The user scrolls the document. The
search box loses focus in any way at all.

(The original report mentions emacs. Emacs has stuff like this but does it even differently than I would suggest we do here, effectively limiting the typical backspace functionality of removing a character. The original report mentions this, and states "I am somewhat ambivalent on this point and not convinced that it offers real advantage." In comment #3, the emacs behaviour is viewed more favorably though. I'll just leave it at that for now.)

(That's all for now. Really sorry about the spamming for those of you who get email. I thought it might be easier to read it all separated this way.)

Comment 12

[Mike de Boer [:mikedeboer]]

Hugo, I understand what you're trying to say, but I'm afraid that implementing this behavior is not trivial and I'm not sure if the majority of web browser users (not experienced with fancy text editors boasting extravagant find-in-page features) will understand what's going on.
We don't even provide regex-search and for a good reason.

Comment 13

[Martijn Wargers (dead)]

(In reply to Mike de Boer [:mikedeboer] from comment #12)
> We don't even provide regex-search and for a good reason.

Why not?

Comment 14

[Mike de Boer [:mikedeboer]]

(In reply to Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) from comment #13)
> Why not?

Because implementing that behavior is not trivial and I'm not sure if the majority of web browser users (not experienced with fancy text editors boasting extravagant find-in-page features) will understand how to use it.
For most software developers, 'regex' is familiar jargon. For the rest of world it's quite the opposite.

Comment 15

[Martijn Wargers (dead)]

I guess if Gecko is only meant for simple consumable applications, then we don't need 'regex', I guess nowadays no editor applications are there anymore that use Gecko as a platform.

Comment 16

[Hugo Heden]

(In reply to Mike de Boer [:mikedeboer] from comment #12)
> Hugo, I understand what you're trying to say, but I'm afraid that
> implementing this behavior is not trivial and I'm not sure if the majority
> of web browser users (not experienced with fancy text editors boasting
> extravagant find-in-page features) will understand what's going on.

Understood and accepted. 

Perhaps it would be possible to implement all this as a Firefox extension or something.

> We don't even provide regex-search and for a good reason.

Agreed. (Just note that the bug report has nothing to do with regex searches. It's rather about emacs-style-find-as-you-type, where the found-selection jump backwards if the user corrects a mistake in the search box.)

Thanks for taking your time on this.

Comment 17

[Mike de Boer [:mikedeboer]]

(In reply to Hugo Heden from comment #16)
> Perhaps it would be possible to implement all this as a Firefox extension or
> something.


I think that could certainly be done - but also here: not trivial :-) But there are many non-trivial things implemented as add-ons, so I wouldn't be surprised if it came to be!