Add a feature which, when enabled, blocks permissions after X prompt dismissals.

chrome/browser/permissions/permission_context_base.cc

Index: chrome/browser/permissions/permission_context_base.cc
diff --git a/chrome/browser/permissions/permission_context_base.cc b/chrome/browser/permissions/permission_context_base.cc
index 8ce7f18b287fe0885a835bc862d313c02bbf2370..8e451b50f6782a09d3d64286d7a4cc2641973139 100644
--- a/chrome/browser/permissions/permission_context_base.cc
+++ b/chrome/browser/permissions/permission_context_base.cc
@@ -216,6 +216,15 @@ void PermissionContextBase::PermissionDecided(
   PermissionRequestGestureType gesture_type =
       user_gesture ? PermissionRequestGestureType::GESTURE
                    : PermissionRequestGestureType::NO_GESTURE;
+
+  // Check if we should convert a dismiss decision into a block decision. This
+  // is gated on enabling the kBlockPromptsIfDismissedOften feature.
+  if (!persist && PermissionUtil::ShouldChangeDismissalToBlock(
+                      profile_, requesting_origin, permission_type_)) {
+    persist = true;

[raymes, 2016/07/28 08:07:50]

Hmm I think right now this will cause PermissionUmaUtil::PermissionDenied to be
called below instead of Dismissed. Also, I think we could tweak this a bit for
readability (this logic could be beside PermissionUmaUtil::PermissionDismissed).

[kcarattini, 2016/07/28 08:54:49]

Is that not what we want? Do we want to measure something else? I'm not sure
"dismissed" is the right metric to record in this case. We should decide on what
we want to measure and what change in which metrics are required for meaningful
results upfront. What does success look like?

[dominickn, 2016/08/01 01:08:51]

With respect to metrics, we have a couple of paths here:

1. don't add any specific metrics, and just compare what the existing metrics
look like. The ~25% dismissals should drop and denys should increase.
2. add a new specific metric for dismissal -> deny. I thought about this, and
wondered whether it was worth adding a new metric per permission type just for
this experiment.
3. add a new bucket to the Permission.Action.* metric, which is dismissal ->
deny. This was the option I was most leaning towards, but it does mean another
(often not meaningful) bucket in that histogram.

Thoughts?

[dominickn, 2016/08/01 01:08:51]

This was a deliberate choice - I wanted the triggering dismissal to simply turn
into a deny, which was why I structured the code like this. Do you prefer it
some other way?

[raymes, 2016/08/01 05:09:11]

This is supposed to measure a user's action on the permission prompt. In this
case, the user is still clicking the dismiss button, so I think we should still
record a dismiss. We should really update the names of PermissionGranted, etc.
to make it clear what we're measuring.

As to what metrics we should use, I'm flexible with all those approaches. Adding
to Permission.Action isn't the best in my mind because it's not really a
separate action from the user's perspective (they're still just dismissing) and
it might confuse the dismiss metrics. The others sound good though.

[kcarattini, 2016/08/01 07:09:52]

As discussed, I think we should move this discussion to a doc. Will be useful
for future experiments as well.

+    content_setting = CONTENT_SETTING_BLOCK;
+  }
+
   if (persist) {
     DCHECK(content_setting == CONTENT_SETTING_ALLOW ||
            content_setting == CONTENT_SETTING_BLOCK);