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 3f2dc43dd569f30773e1c7f8130dbb77af3509b2..7511abd5c133e37d6f377196a4dd1bffb75cfc13 100644
--- a/chrome/browser/ui/views/location_bar/location_bar_view.cc
+++ b/chrome/browser/ui/views/location_bar/location_bar_view.cc
@@ -1097,6 +1097,16 @@ bool LocationBarView::GetBookmarkStarVisibility() {
   return star_view_->visible();
 }
 
+int LocationBarView::ContentSettingImageModelCount() {
+  return content_setting_views_.size();

[Peter Kasting, 2017/02/06 21:14:25]

This is a size_t, so the function should return a size_t (and callers of it
should store the results in a size_t, etc.)

+}
+
+ContentSettingImageModel* LocationBarView::GetContentSettingImageModel(
+    size_t index) {
+  DCHECK_LT(index, content_setting_views_.size());
+  return content_setting_views_.at(index)->content_setting_image_model();

[Peter Kasting, 2017/02/06 21:14:25]

Nit: At least in location_bar code, don't use at().  Use [].  (See my previous
drive-by comments; I don't speak for what Mac wants to do, but I'd rather not
use at() here.)

+}
+
 ////////////////////////////////////////////////////////////////////////////////
 // LocationBarView, private views::View implementation:
 
@@ -1218,3 +1228,19 @@ void LocationBarView::OnTemplateURLServiceChanged() {
   if (omnibox_view_ && omnibox_view_->GetWidget()->IsActive())
     ShowFirstRunBubble();
 }
+
+////////////////////////////////////////////////////////////////////////////////
+// LocationBarView, private function(s) for testing:
+
+ContentSettingImageView*
+LocationBarView::GetContentSettingImageViewFromImageModel(
+    ContentSettingImageModel* image_model) {
+  for (auto view : content_setting_views_) {

[tapted, 2017/02/03 23:07:03]

The guide says we can use auto for "cases where the type doesn't aid in clarity
for the reader." - I don't think that's the case here when compared to
ContentSettingImageView*

(also seeing raw `auto` without `auto*` or `const auto&` also means we have to
question whether we are invoking the copy constructor by accident, but that's
orthogonal).

See http://go/cppguide#auto

[Peter Kasting, 2017/02/06 21:14:25]

I would use [const] auto* here, personally.  I agree that auto* is better than
auto, but I think auto* is sufficiently clear here and we don't really need
ContentSettingImageView*.  That said, I don't care much; I am OK with either
route.

+    if (view->content_setting_image_model() == image_model)
+      return view;
+  }
+  NOTREACHED();
+  return nullptr;
+}
+
+