DialogBrowserTest implementation to invoke Content settings bubble dialogs.

chrome/browser/ui/views/location_bar/location_bar_view.cc

Index: chrome/browser/ui/views/location_bar/location_bar_view.cc
diff --git a/chrome/browser/ui/views/location_bar/location_bar_view.cc b/chrome/browser/ui/views/location_bar/location_bar_view.cc
index a37de8a5213311b147b0baffddc3d5117ff634b2..ef52bfa6784901e89e6f41f866cf646f4af4b0c1 100644
--- a/chrome/browser/ui/views/location_bar/location_bar_view.cc
+++ b/chrome/browser/ui/views/location_bar/location_bar_view.cc
@@ -1074,6 +1074,18 @@ bool LocationBarView::GetBookmarkStarVisibility() {
   return star_view_->visible();
 }
 
+bool LocationBarView::TestContentSettingImagePressed(size_t index) {
+  if (index >= content_setting_views_.size())
+    return false;
+
+  // This up-cast is necessary since the descendant class moved OnKeyPressed
+  // to the protected section.

[Peter Kasting, 2017/02/15 01:14:01]

My instinct is that we should just make that public again and then go with the
inlined, no-comment version.

This is OK too.

[kylix_rd, 2017/02/15 16:42:59]

Yes, true. However, moving overrides to private seem to be all the rage in many
places I've looked. IMO, if anything is done about that, it should be a separate
refactoring pass.
 

[Peter Kasting, 2017/02/15 19:11:39]

I'm usually responsible for pushing for that -- my default policy is "make
overrides as private as possible".  I wasn't thinking so much of reversing that
on a policy level, as simply saying "for this class, someone external needs to
access this" and having that be reasonable justification for making it public.

+  views::View* image_view = content_setting_views_[index];
+  image_view->OnKeyReleased(
+      ui::KeyEvent(ui::ET_KEY_RELEASED, ui::VKEY_SPACE, ui::EF_NONE));
+  return true;
+}
+
 ////////////////////////////////////////////////////////////////////////////////
 // LocationBarView, private views::View implementation: