Fix find box bug after navigation.

Fix find box bug after navigation.

The bug is that after searching for a string that is not on the page, if
you then navigate to a page that DOES contain that string, find-in-page
will still find no matches.

What is actually happening in the search after navigation is that even
though TextFinder::find() is returning true (to indicate that a match is
found), the field |m_lastFindRequestCompletedWithNoMatches| is still
false (from the last page, which had no matches). This prevents any
matches from being highlighted during the subsequent scoping effort.

The simple (and correct) fix is to set
|m_lastFindRequestCompletedWithNoMatches| to false if a match is found
in TextFinder::find() (since the find request no longer has no matches).

BUG=644448
Committed: https://crrev.com/d3b32d5fe57bf7cf749d057e1944321735ae8e1e
Cr-Commit-Position: refs/heads/master@{#417095}

[paulmeyer, 2016-09-07 15:26:05]

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

[paulmeyer, 2016-09-07 15:26:06]

+pdr@ for review.

[pdr., 2016-09-07 17:41:39]

On 2016/09/07 at 15:26:06, paulmeyer wrote:
> +pdr@ for review.

Thanks for the fix! This bug drives me crazy.

Can you add a test for this?

[paulmeyer, 2016-09-07 18:41:59]

Test added. PTAL.

[pdr., 2016-09-07 20:14:58]

On 2016/09/07 at 18:41:59, paulmeyer wrote:
> Test added. PTAL.

LGTM! Really happy to see this one squashed.


Minor nit: can you please wrap the change description to 72 columns before
landing?

[paulmeyer, 2016-09-07 20:17:33]

Description was changed from

==========
Fix find box bug after navigation.

The bug is that after searching for a string that is not on the page, if you
then navigate to a page that DOES contain that string, find-in-page will still
find no matches.

What is actually happening in the search after navigation is that even though
TextFinder::find() is returning true (to indicate that a match is found), the
field |m_lastFindRequestCompletedWithNoMatches| is still false (from the last
page, which had no matches). This prevents any matches from being highlighted
during the subsequent scoping effort.

The simple (and correct) fix is to set |m_lastFindRequestCompletedWithNoMatches|
to false if a match is found in TextFinder::find() (since the find request no
longer has no matches).

BUG=644448
==========

to

==========
Fix find box bug after navigation.

The bug is that after searching for a string that is not on the page, if
you then navigate to a page that DOES contain that string, find-in-page
will still find no matches.

What is actually happening in the search after navigation is that even
though TextFinder::find() is returning true (to indicate that a match is
found), the field |m_lastFindRequestCompletedWithNoMatches| is still
false (from the last page, which had no matches). This prevents any
matches from being highlighted during the subsequent scoping effort.

The simple (and correct) fix is to set
|m_lastFindRequestCompletedWithNoMatches| to false if a match is found
in TextFinder::find() (since the find request no longer has no matches).

BUG=644448
==========

[paulmeyer, 2016-09-07 20:18:03]

The CQ bit was checked by paulmeyer@chromium.org

[commit-bot: I haz the power, 2016-09-07 20:18:48]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-07 22:25:14]

Description was changed from

==========
Fix find box bug after navigation.

The bug is that after searching for a string that is not on the page, if
you then navigate to a page that DOES contain that string, find-in-page
will still find no matches.

What is actually happening in the search after navigation is that even
though TextFinder::find() is returning true (to indicate that a match is
found), the field |m_lastFindRequestCompletedWithNoMatches| is still
false (from the last page, which had no matches). This prevents any
matches from being highlighted during the subsequent scoping effort.

The simple (and correct) fix is to set
|m_lastFindRequestCompletedWithNoMatches| to false if a match is found
in TextFinder::find() (since the find request no longer has no matches).

BUG=644448
==========

to

==========
Fix find box bug after navigation.

The bug is that after searching for a string that is not on the page, if
you then navigate to a page that DOES contain that string, find-in-page
will still find no matches.

What is actually happening in the search after navigation is that even
though TextFinder::find() is returning true (to indicate that a match is
found), the field |m_lastFindRequestCompletedWithNoMatches| is still
false (from the last page, which had no matches). This prevents any
matches from being highlighted during the subsequent scoping effort.

The simple (and correct) fix is to set
|m_lastFindRequestCompletedWithNoMatches| to false if a match is found
in TextFinder::find() (since the find request no longer has no matches).

BUG=644448
==========

[commit-bot: I haz the power, 2016-09-07 22:25:15]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-09-07 22:26:47]

Description was changed from

==========
Fix find box bug after navigation.

The bug is that after searching for a string that is not on the page, if
you then navigate to a page that DOES contain that string, find-in-page
will still find no matches.

What is actually happening in the search after navigation is that even
though TextFinder::find() is returning true (to indicate that a match is
found), the field |m_lastFindRequestCompletedWithNoMatches| is still
false (from the last page, which had no matches). This prevents any
matches from being highlighted during the subsequent scoping effort.

The simple (and correct) fix is to set
|m_lastFindRequestCompletedWithNoMatches| to false if a match is found
in TextFinder::find() (since the find request no longer has no matches).

BUG=644448
==========

to

==========
Fix find box bug after navigation.

The bug is that after searching for a string that is not on the page, if
you then navigate to a page that DOES contain that string, find-in-page
will still find no matches.

What is actually happening in the search after navigation is that even
though TextFinder::find() is returning true (to indicate that a match is
found), the field |m_lastFindRequestCompletedWithNoMatches| is still
false (from the last page, which had no matches). This prevents any
matches from being highlighted during the subsequent scoping effort.

The simple (and correct) fix is to set
|m_lastFindRequestCompletedWithNoMatches| to false if a match is found
in TextFinder::find() (since the find request no longer has no matches).

BUG=644448

Committed: https://crrev.com/d3b32d5fe57bf7cf749d057e1944321735ae8e1e
Cr-Commit-Position: refs/heads/master@{#417095}
==========

[commit-bot: I haz the power, 2016-09-07 22:26:48]

Patchset 2 (id:??) landed as
https://crrev.com/d3b32d5fe57bf7cf749d057e1944321735ae8e1e
Cr-Commit-Position: refs/heads/master@{#417095}