Add UseCounter to see how often the "allowfullscreen" attribute is modified.

third_party/WebKit/Source/core/html/HTMLIFrameElement.cpp

Index: third_party/WebKit/Source/core/html/HTMLIFrameElement.cpp
diff --git a/third_party/WebKit/Source/core/html/HTMLIFrameElement.cpp b/third_party/WebKit/Source/core/html/HTMLIFrameElement.cpp
index 12457460b7b20b3f17c50c8fe861b380e63af822..065711d074fdcca9c5d10b6da8559cc8b440006e 100644
--- a/third_party/WebKit/Source/core/html/HTMLIFrameElement.cpp
+++ b/third_party/WebKit/Source/core/html/HTMLIFrameElement.cpp
@@ -125,8 +125,13 @@ void HTMLIFrameElement::parseAttribute(
   } else if (name == allowfullscreenAttr) {
     bool oldAllowFullscreen = m_allowFullscreen;
     m_allowFullscreen = !value.isNull();
-    if (m_allowFullscreen != oldAllowFullscreen)
+    if (m_allowFullscreen != oldAllowFullscreen) {
+      if (contentFrame()) {

[foolip, 2017/02/05 23:22:08]

I believe this means roughly "has this iframe loaded", but does the null-ness of
contentFrame() change at exactly the time that feature policy and sanbox
attributes are snapshotted?

I have no reason to suspect that it'd inflate the numbers, but this counter also
includes a case where the allowfullscreen attribute is removed after load. Don't
know why you'd do that, but interwebs are full of surprises.

[iclelland, 2017/02/06 20:15:25]

Sandbox attributes are snapshotted in |WebLocalFrameImpl::createChildFrame,
immediately before |WebLocalFrameImpl::initializeCoreFrame| is called. During
that method, the |m_contentFrame| member is set (through LocalFrame::create.)

|m_contentFrame| is nulled when the frame is detached from the document. If
reattached, the new frame contents are initialized the same way.

This is not reset on subframe navigation, though, so it won't catch the pattern
of Add Iframe -> Change Attribute -> Navigate -> Request Fullscreen; that will
look like a blocked fullscreen request.
That's deliberate, as it would also be a situation in which snapshotting would
change existing behaviour. (If a site tried to block an otherwise allowed
fullscreen request by removing the attribute)

Both of these issues, I believe, will cause us to overcount the impact of this
change. We could tighten this up, to try to only catch the exact situation where
fullscreen would break, but that should be a strictly smaller number than this
one. I'd like to land this counter, to try to merge to M57, to get as much data
as we can. I'll add the other, tighter use counter in a separate CL if you're
okay with that.

+        UseCounter::count(
+            document(), UseCounter::HTMLIFrameElementAllowfullscreenAttribute);

[foolip, 2017/02/05 23:22:08]

Can you append "ChangedAfterContentLoad" or something like that? People
sometimes go hunting in chromestatus.com for counters to answer a particular
question, and counters cover much more or less than the name suggest can
confuse. (Obviously 100% precision is not reasonable though.)

[iclelland, 2017/02/06 20:15:25]

Done.

+      }
       frameOwnerPropertiesChanged();
+    }
   } else if (name == allowpaymentrequestAttr) {
     bool oldAllowPaymentRequest = m_allowPaymentRequest;
     m_allowPaymentRequest = !value.isNull();