Measure the usage of navigator.vibrate in for user gesture & subframe.

third_party/WebKit/Source/modules/vibration/NavigatorVibration.cpp

Index: third_party/WebKit/Source/modules/vibration/NavigatorVibration.cpp
diff --git a/third_party/WebKit/Source/modules/vibration/NavigatorVibration.cpp b/third_party/WebKit/Source/modules/vibration/NavigatorVibration.cpp
index ae5ca2c5c3622862bdb791b90a39b4e520bbbc8e..5d3a843d239b0be2132d70b48104eb46692f1f5b 100644
--- a/third_party/WebKit/Source/modules/vibration/NavigatorVibration.cpp
+++ b/third_party/WebKit/Source/modules/vibration/NavigatorVibration.cpp
@@ -24,6 +24,8 @@
 #include "core/frame/UseCounter.h"
 #include "core/page/Page.h"
 #include "modules/vibration/VibrationController.h"
+#include "platform/Histogram.h"
+#include "platform/UserGestureIndicator.h"
 
 namespace blink {
 
@@ -81,6 +83,11 @@ bool NavigatorVibration::vibrate(Navigator& navigator, const VibrationPattern& p
     if (!frame->page()->isPageVisible())
         return false;
 
+    if (frame->isCrossOrigin()) {

[Michael van Ouwerkerk, 2016/06/20 13:00:01]

Recording whether a user gesture is present would also be useful if it's not
cross origin.

+        DEFINE_STATIC_LOCAL(EnumerationHistogram, crossOriginVibrateHistogram, ("WebModules.CrossOriginVibrate", 2));
+        crossOriginVibrateHistogram.count(UserGestureIndicator::processingUserGesture() ? 1 : 0);

[Michael van Ouwerkerk, 2016/06/20 13:00:01]

To make the data consistent with the use counters above, this should all go
before the early return for page visibility.

+    }

[mlamouri (slow - plz ping), 2016/06/20 10:39:20]

Would that make sense to integrate with the NavigatorVibrate and
NavigatorVibrateSubFrame above? FWIW, NavigatorVibrateSubFrame already has a
very low value. The issue here is that vibrate is abused a lot on mobile with
popups (so they are top frames).

[ojan, 2016/06/20 14:04:09]

I didn't realize we had NavigatorVibrateSubFrame already.

Looking at our internal numbers, ~0.16% of android page views use
NavigatorVibrate and ~0.0064% hit NavigatorVibrateSubFrame. I suspect a large
percentage of the latter are ads that are user annoyance.

IMO, we don't need more numbers. We should put together an intent to implement
and ship to disable vibrate inside cross origin frames. The intent should
clarify that we'll allow it again in the future once we figure out the shape of
the permissions API.
Ugh. That's something we'll need to solve in a different way I think. I think
changing cross-origin frames to disallow vibrate by default is still a valuable
change though, yeah?

+
     return NavigatorVibration::from(navigator).controller()->vibrate(pattern);
 }