Handling new frames and frame navigations with find-in-page during a find session.

third_party/WebKit/Source/web/WebLocalFrameImpl.cpp

Index: third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
diff --git a/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp b/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
index b87220317549301a2c971a87deec6e32280cda35..a25f18468d25aa36577b2affbaf1ed9588334a41 100644
--- a/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
+++ b/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
@@ -1940,7 +1940,7 @@ void WebLocalFrameImpl::didCallIsSearchProviderInstalled()
 void WebLocalFrameImpl::requestFind(int identifier, const WebString& searchText, const WebFindOptions& options)
 {
     // Send "no results" if this frame has no visible content.
-    if (!hasVisibleContent()) {
+    if (!hasVisibleContent() && !options.force) {

[dcheng, 2016/09/21 07:15:44]

Why do we want to force a research if the frame's not visible? I don't think I
understand the ordering of these two checks (above as well)

[paulmeyer, 2016/09/21 15:40:52]

This is because hasVisibleContent() is not perfect. It sometimes returns false
when the frame does have visible content. I wasn't able to find an easy way to
fix this function (and that's outside the scope of my patch), so I just bypassed
it to make sure the frame gets searched if it is specified that it should be
forcibly re-searched. I think that makes sense anyways that it shouldn't be held
up by something like this if you're forcing it to be searched.

[dcheng, 2016/09/22 00:36:47]

Hmm, what are the cases where it's wrong? Would it make sense to file a bug?

[paulmeyer, 2016/09/22 15:11:42]

Okay, I'll try to file a bug. It's been a while since I originally looked into
what was wrong with it though, so I'll have to do a bit more digging before I
can say for sure which cases reproduce the bug.

         client()->reportFindInPageMatchCount(identifier, 0 /* count */, true /* finalUpdate */);
         return;
     }