Search box working improperly after navigating to another page |
||||
Issue description
<b>Chrome Version : <Copy from: 'about:version'></b>
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari:
Firefox:
IE:
What steps will reproduce the problem?
(1) Navigate to page A (say, https://en.wikipedia.org)
(2) Press Ctrl+F
(3) Type a string S (say, "Willkommen") which is not present on page A
Result: no matches (as expected)
(4) Without removing S from the search box, and without pressing escape, navigate (by clicking a link or typing a new address) to page B (say, https://de.wikipedia.org) which contains string S
Result: search box disappears (OK)
(5) Press Ctrl+F again
Result: search box appears again, and it still contains S, and it does not yet inform about the number of matches
(6) Press Enter
Result: search box reports 0 matches --- wrong!
Reproduced also in another setting (for Buganizer pages).
What is the expected result?
In the above example, the search box should report 1 match.
What happens instead?
0 matches reported.
Please provide any additional information below. Attach a screenshot if
possible.
OS: Goobuntu
Chrome version: 53.0.2785.89 (64-bit)
Screenshots:
- after step 3: https://screenshot.googleplex.com/4Yy7DOrGi7X
- between 3 and 4: https://screenshot.googleplex.com/6AvkOn03HXK
- after step 5: https://screenshot.googleplex.com/VrNYdtFztCN
- after step 6: https://screenshot.googleplex.com/ScLhBQhMPWH
,
Sep 7 2016
,
Sep 7 2016
,
Sep 7 2016
I have a fix in review: https://codereview.chromium.org/2316203002/
,
Sep 7 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d3b32d5fe57bf7cf749d057e1944321735ae8e1e commit d3b32d5fe57bf7cf749d057e1944321735ae8e1e Author: paulmeyer <paulmeyer@chromium.org> Date: Wed Sep 07 22:24:55 2016 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 Review-Url: https://codereview.chromium.org/2316203002 Cr-Commit-Position: refs/heads/master@{#417095} [modify] https://crrev.com/d3b32d5fe57bf7cf749d057e1944321735ae8e1e/content/browser/find_request_manager_browsertest.cc [add] https://crrev.com/d3b32d5fe57bf7cf749d057e1944321735ae8e1e/content/test/data/find_in_simple_page.html [modify] https://crrev.com/d3b32d5fe57bf7cf749d057e1944321735ae8e1e/third_party/WebKit/Source/web/TextFinder.cpp
,
Sep 8 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by kavvaru@chromium.org
, Sep 7 2016Labels: -Type-Bug -Pri-3 M-53 hasbisect OS-Linux OS-Mac OS-Windows Pri-1 Type-Bug-Regression
Owner: paulmeyer@chromium.org
Status: Assigned (was: Unconfirmed)