DialogBrowserTest implementation to invoke Content settings bubble dialogs.

chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm

Index: chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm
diff --git a/chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm b/chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm
index 5c4a91e5b43a8b01b66e2755aa1c50d1582fbc0f..7cc34f14f15b19a968d7dd22f0b4db408e2e4de9 100644
--- a/chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm
+++ b/chrome/browser/ui/cocoa/location_bar/location_bar_view_mac.mm
@@ -332,6 +332,16 @@ bool LocationBarViewMac::GetBookmarkStarVisibility() {
   return star_decoration_->IsVisible();
 }
 
+int LocationBarViewMac::ContentSettingImageModelCount() {
+  return content_setting_decorations_.size();
+}
+
+ContentSettingImageModel* LocationBarViewMac::GetContentSettingImageModel(
+    size_t index) {
+  DCHECK(index >= 0 && index < content_setting_decorations_.size());

[tapted, 2017/02/03 00:35:39]

optional: remove - .at(..) will throw an exception, which is as effective as the
DCHECK
otherwise (non-optional ;)): remove `index >= 0` since it is a tautology (index
is unsigned) and do DCHECK_LT(index, content_setting_decorations_.size())

(we could also make |index| an int - that's closer to style guide
recommendations, but it would make it inconsistent with the other methods on the
interface)

[kylix_rd, 2017/02/03 18:55:03]

Are exceptions OK in the Mac world?
Ah, right. It was an int originally and I changed it to match the other methods
and neglected to update the DCHECK. Good catch. I also didn't know about
DCHECK_LT. Thanks.
Agreed. I'd rather be consistent in this instance. 'size_t' makes more sense
anyway. I think there were some discussions about making some changes WRT using
size_t for indices.

[Peter Kasting, 2017/02/03 22:20:41]

For reference, in .cc files I ask people to avoid .at(), because the difference
between it and [] is unclear to most readers, especially in Chromium where
exceptions are disabled.  [] + DCHECK is more idiomatic.

I don't know if Cocoa has a different pattern.
size_t is not just OK but encouraged per the Google and Chromium style guides. 
See e.g.
https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md...
.

Basically, if size_t is conceptually correct, don't use int.

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

I think the C++ library is pre-built with exceptions enabled - they don't get
turned off there with -fno-exceptions - the code that calls std::terminate()
when the exception is unhandled will then kick in since there's no code in
Chrome to handle it. (pretty sure this is true everywhere.. but I've seen some
exceptions-disabled library blobs shipped for Windows things in the past).

(And, annoyingly, on Mac we can't use AppKit without exceptions -- there are
some library behaviours that can only be dealt with using exception handlers, so
we can't compile with -fno-exceptions the way we do on linux).

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

Ooh nice! I'm glad we clarify this.

go/cppguide and https://google.github.io/styleguide/cppguide.html

still say "Of the C integer types, only int should be used. When appropriate,
you are welcome to use standard types like size_t and ptrdiff_t.".  which always
bugged me - I read it as ~"prefer int unless you need size_t".

+  return content_setting_decorations_.at(index)->content_setting_image_model();
+}
+
 void LocationBarViewMac::SetEditable(bool editable) {
   [field_ setEditable:editable ? YES : NO];
   UpdateBookmarkStarVisibility();