Log to UMA when x-origin frames (1) are created and (2) become visible

third_party/WebKit/Source/core/loader/DocumentLoader.cpp

Index: third_party/WebKit/Source/core/loader/DocumentLoader.cpp
diff --git a/third_party/WebKit/Source/core/loader/DocumentLoader.cpp b/third_party/WebKit/Source/core/loader/DocumentLoader.cpp
index e80d27fe57157e57b4e657e4dff21b0e965700f2..249536ca3045fbbfed0aac29db8665773d17d3ca 100644
--- a/third_party/WebKit/Source/core/loader/DocumentLoader.cpp
+++ b/third_party/WebKit/Source/core/loader/DocumentLoader.cpp
@@ -695,6 +695,8 @@ DocumentWriter* DocumentLoader::createWriterFor(const DocumentInit& init, const
         frame->document()->setBaseURLOverride(overridingURL);
 
     frame->loader().didInstallNewDocument(dispatchWindowObjectAvailable);
+    if (frame->loader().stateMachine()->committedFirstRealDocumentLoad())
+        frame->didInstallNewRealDocument();

[dcheng, 2016/08/26 18:28:29]

I think it would be nicer if we could do this without adding a new callback.

There are several approaches: the easiest is to probably just move the creation
logging trigger into DOcument's constructor, after we call initSecurityContext.

However, this raises an interesting question: what do we want to time? If we
time from the creation of the cross-origin document to when it becomes visible,
this is not actually the same as the timing of the creation of the initial frame
to when the cross-origin document loads.

The problem, of course, is that we don't /know/ that a LocalFrame is going to be
used for a cross-origin document until the actual navigation commits.

[dgrogan, 2016/08/26 18:54:06]

This allowed the enum and logging code to live solely in LocalFrame.cpp, and not
be exposed to anything else, which is a nice property.
I might be nitpicking here, but we're not trying to time anything, just count.
Maybe you are using those terms interchangeably?

But to get at the crux of your question, I think it doesn't matter exactly what
we count (yet). For now we're trying to get a first rough estimate of the effect
of a potential future intervention. As long as we're not off by a factor of 2-3,
we're fine.

Instead of being frame-centric, as this CL has been so far, we could be
document-centric and measure (x-origin documents that have been loaded in a
visible frame) / (x-origin documents that have been created). Do you think that
would lead to something cleaner?

 
     // This must be called before DocumentWriter is created, otherwise HTML parser
     // will use stale values from HTMLParserOption.