Removed limitation on searching frames for the same string prefix.

Remove limitation on searching frames for the same string prefix.

An optimization has existed in TextFinder:shouldScopeMatches() for a long
time that prevents a frame from being searched (via find-in-page) for a
string with the same prefix as a search that previously returned no matches.
For example, if a frame is searched for the string "dog" with no results,
then this function would never allow a search for "dogs", even after content
in the frame has changed (so "dogs" could be in there).

This optimization has been causing various bugs that I've had to address for
quite a while, and there are still new bugs coming up because of it now, so
I'd like to just remove it. It does occasionally prevent starting a search
when there are no matches, but these searches would exit early anyways when
no active match is found, so I don't think there is much savings from it. On
the other hand, when content in the frame changes, and there are new matches
to be found, this optimization causes find-in-page to fail when it
shouldn't.

It is possible that something more complicated could be implemented in order
to keep the optimization but detect content changes so that it does the
right thing in that case, but the extra overhead of this may cancel out any
savings had by avoiding a few searches here and there anyways, so I don't
think that is worthwhile.

BUG=2220, 655282, 652267, 657709

[paulmeyer, 2016-10-17 16:03:33]

Description was changed from

==========
Removed limitation on searching frames for the same string prefix.

An optimization has existed in TextFinder:shouldScopeMatches() for a long
time that prevents a frame from being searched (via find-in-page) for a
string with the same prefix as a search that previously returned no matches.
For example, if a frame is searched for the string "dog" with no results,
then this function would never allow a search for "dogs", even after content
in the frame has changed.

This optimization has been causing various bugs that I've had to address for
a long time, and there are still new bugs coming up because of it now, so
I'd like to just remove it. It does occasionally prevent starting a search
when there are no matches, but these searches would exit early anyways when
no active match is found, so I don't think there is much savings from it. On
the other hand, when content in the frame changes, and there are new matches
to be found, this optimization causes find-in-page to fail when it
shouldn't.

It is possible that something more complicated could be implemented in order
to keep the optimization but detect content changes so that it does the
right thing in that case, but the extra overhead of this may cancel out any
savings had by avoiding a few searches here and there anyways, so I don't
think that is worthwhile.

BUG=2220, 655282
==========

to

==========
Remove limitation on searching frames for the same string prefix.

An optimization has existed in TextFinder:shouldScopeMatches() for a long
time that prevents a frame from being searched (via find-in-page) for a
string with the same prefix as a search that previously returned no matches.
For example, if a frame is searched for the string "dog" with no results,
then this function would never allow a search for "dogs", even after content
in the frame has changed.

This optimization has been causing various bugs that I've had to address for
a long time, and there are still new bugs coming up because of it now, so
I'd like to just remove it. It does occasionally prevent starting a search
when there are no matches, but these searches would exit early anyways when
no active match is found, so I don't think there is much savings from it. On
the other hand, when content in the frame changes, and there are new matches
to be found, this optimization causes find-in-page to fail when it
shouldn't.

It is possible that something more complicated could be implemented in order
to keep the optimization but detect content changes so that it does the
right thing in that case, but the extra overhead of this may cancel out any
savings had by avoiding a few searches here and there anyways, so I don't
think that is worthwhile.

BUG=2220, 655282
==========

[paulmeyer, 2016-10-17 16:04:12]

Description was changed from

==========
Remove limitation on searching frames for the same string prefix.

An optimization has existed in TextFinder:shouldScopeMatches() for a long
time that prevents a frame from being searched (via find-in-page) for a
string with the same prefix as a search that previously returned no matches.
For example, if a frame is searched for the string "dog" with no results,
then this function would never allow a search for "dogs", even after content
in the frame has changed.

This optimization has been causing various bugs that I've had to address for
a long time, and there are still new bugs coming up because of it now, so
I'd like to just remove it. It does occasionally prevent starting a search
when there are no matches, but these searches would exit early anyways when
no active match is found, so I don't think there is much savings from it. On
the other hand, when content in the frame changes, and there are new matches
to be found, this optimization causes find-in-page to fail when it
shouldn't.

It is possible that something more complicated could be implemented in order
to keep the optimization but detect content changes so that it does the
right thing in that case, but the extra overhead of this may cancel out any
savings had by avoiding a few searches here and there anyways, so I don't
think that is worthwhile.

BUG=2220, 655282
==========

to

==========
Remove limitation on searching frames for the same string prefix.

An optimization has existed in TextFinder:shouldScopeMatches() for a long
time that prevents a frame from being searched (via find-in-page) for a
string with the same prefix as a search that previously returned no matches.
For example, if a frame is searched for the string "dog" with no results,
then this function would never allow a search for "dogs", even after content
in the frame has changed (so "dogs" could be in there).

This optimization has been causing various bugs that I've had to address for
a long time, and there are still new bugs coming up because of it now, so
I'd like to just remove it. It does occasionally prevent starting a search
when there are no matches, but these searches would exit early anyways when
no active match is found, so I don't think there is much savings from it. On
the other hand, when content in the frame changes, and there are new matches
to be found, this optimization causes find-in-page to fail when it
shouldn't.

It is possible that something more complicated could be implemented in order
to keep the optimization but detect content changes so that it does the
right thing in that case, but the extra overhead of this may cancel out any
savings had by avoiding a few searches here and there anyways, so I don't
think that is worthwhile.

BUG=2220, 655282
==========

[paulmeyer, 2016-10-17 16:04:41]

Description was changed from

==========
Remove limitation on searching frames for the same string prefix.

An optimization has existed in TextFinder:shouldScopeMatches() for a long
time that prevents a frame from being searched (via find-in-page) for a
string with the same prefix as a search that previously returned no matches.
For example, if a frame is searched for the string "dog" with no results,
then this function would never allow a search for "dogs", even after content
in the frame has changed (so "dogs" could be in there).

This optimization has been causing various bugs that I've had to address for
a long time, and there are still new bugs coming up because of it now, so
I'd like to just remove it. It does occasionally prevent starting a search
when there are no matches, but these searches would exit early anyways when
no active match is found, so I don't think there is much savings from it. On
the other hand, when content in the frame changes, and there are new matches
to be found, this optimization causes find-in-page to fail when it
shouldn't.

It is possible that something more complicated could be implemented in order
to keep the optimization but detect content changes so that it does the
right thing in that case, but the extra overhead of this may cancel out any
savings had by avoiding a few searches here and there anyways, so I don't
think that is worthwhile.

BUG=2220, 655282
==========

to

==========
Remove limitation on searching frames for the same string prefix.

An optimization has existed in TextFinder:shouldScopeMatches() for a long
time that prevents a frame from being searched (via find-in-page) for a
string with the same prefix as a search that previously returned no matches.
For example, if a frame is searched for the string "dog" with no results,
then this function would never allow a search for "dogs", even after content
in the frame has changed (so "dogs" could be in there).

This optimization has been causing various bugs that I've had to address for
quite a while, and there are still new bugs coming up because of it now, so
I'd like to just remove it. It does occasionally prevent starting a search
when there are no matches, but these searches would exit early anyways when
no active match is found, so I don't think there is much savings from it. On
the other hand, when content in the frame changes, and there are new matches
to be found, this optimization causes find-in-page to fail when it
shouldn't.

It is possible that something more complicated could be implemented in order
to keep the optimization but detect content changes so that it does the
right thing in that case, but the extra overhead of this may cancel out any
savings had by avoiding a few searches here and there anyways, so I don't
think that is worthwhile.

BUG=2220, 655282
==========

[paulmeyer, 2016-10-17 16:30:33]

Patchset #1 (id:1) has been deleted

[paulmeyer, 2016-10-17 16:41:25]

paulmeyer@chromium.org changed reviewers:
+ dcheng@chromium.org

[paulmeyer, 2016-10-17 16:41:25]

+dcheng@ for review

[dcheng, 2016-10-17 18:17:41]

Incidentally, do we have any metrics that measure this? It would be at least
somewhat useful to know how much this affects perf.

https://codereview.chromium.org/2428613002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/TextFinder.h (right):

https://codereview.chromium.org/2428613002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/TextFinder.h:233: WTF::String m_lastSearchString;
Can we get rid of this (and maybe m_lastMatchCount)? It's not clear to me what
parts of this accounting are important.

[paulmeyer, 2016-10-21 16:01:59]

Description was changed from

==========
Remove limitation on searching frames for the same string prefix.

An optimization has existed in TextFinder:shouldScopeMatches() for a long
time that prevents a frame from being searched (via find-in-page) for a
string with the same prefix as a search that previously returned no matches.
For example, if a frame is searched for the string "dog" with no results,
then this function would never allow a search for "dogs", even after content
in the frame has changed (so "dogs" could be in there).

This optimization has been causing various bugs that I've had to address for
quite a while, and there are still new bugs coming up because of it now, so
I'd like to just remove it. It does occasionally prevent starting a search
when there are no matches, but these searches would exit early anyways when
no active match is found, so I don't think there is much savings from it. On
the other hand, when content in the frame changes, and there are new matches
to be found, this optimization causes find-in-page to fail when it
shouldn't.

It is possible that something more complicated could be implemented in order
to keep the optimization but detect content changes so that it does the
right thing in that case, but the extra overhead of this may cancel out any
savings had by avoiding a few searches here and there anyways, so I don't
think that is worthwhile.

BUG=2220, 655282
==========

to

==========
Remove limitation on searching frames for the same string prefix.

An optimization has existed in TextFinder:shouldScopeMatches() for a long
time that prevents a frame from being searched (via find-in-page) for a
string with the same prefix as a search that previously returned no matches.
For example, if a frame is searched for the string "dog" with no results,
then this function would never allow a search for "dogs", even after content
in the frame has changed (so "dogs" could be in there).

This optimization has been causing various bugs that I've had to address for
quite a while, and there are still new bugs coming up because of it now, so
I'd like to just remove it. It does occasionally prevent starting a search
when there are no matches, but these searches would exit early anyways when
no active match is found, so I don't think there is much savings from it. On
the other hand, when content in the frame changes, and there are new matches
to be found, this optimization causes find-in-page to fail when it
shouldn't.

It is possible that something more complicated could be implemented in order
to keep the optimization but detect content changes so that it does the
right thing in that case, but the extra overhead of this may cancel out any
savings had by avoiding a few searches here and there anyways, so I don't
think that is worthwhile.

BUG=2220, 655282, 652267, 657709
==========