Do not reinvent the wheel / use content APIs to find a frame by name.

chrome/browser/autofill/autofill_interactive_uitest.cc

Index: chrome/browser/autofill/autofill_interactive_uitest.cc
diff --git a/chrome/browser/autofill/autofill_interactive_uitest.cc b/chrome/browser/autofill/autofill_interactive_uitest.cc
index cd67195ee1d913c3f0b79eb84e0632611a4cf2ee..b77df4ce7d126143fca965bc542c6fa8611f0e1c 100644
--- a/chrome/browser/autofill/autofill_interactive_uitest.cc
+++ b/chrome/browser/autofill/autofill_interactive_uitest.cc
@@ -215,11 +215,8 @@ class AutofillManagerTestDelegateImpl
 content::RenderFrameHost* RenderFrameHostForName(
     content::WebContents* web_contents,
     const std::string& name) {
-  for (content::RenderFrameHost* frame : web_contents->GetAllFrames()) {
-    if (frame->GetFrameName() == name)
-      return frame;
-  }
-  return nullptr;
+  return content::FrameMatchingPredicate(
+      web_contents, base::Bind(&content::FrameMatchesName, name));

[Łukasz Anforowicz, 2017/04/27 21:36:32]

Given how often the pattern above is used, I wonder if I shouldn't go one step
further and add to content/public/test/browser_test_utils.h a
FrameMatchingName(WebContents, const std::string&) function.  This would allow
ripping out the method reimplemented in the 3 (or 4 depending how you count)
tests I am touching here.

[Łukasz Anforowicz, 2017/04/27 22:59:28]

WDYT about the above?  This would simplify the test code a bit further (at the
cost of exposing everything and a kitchen sync from browser_test_utils.h - this
doesn't seem that bad to me, as long as the new function has a reasonably
obvious name)

[ncarter (slow), 2017/04/27 23:13:35]

Should we instead expose a FindFrameByName to web_contents.h? There seems to be
demand for it in real code.

 }
 
 }  // namespace