Trace FrameTreeNode Snapshots

content/browser/frame_host/traced_frame_tree.cc

Index: content/browser/frame_host/traced_frame_tree.cc
diff --git a/content/browser/frame_host/traced_frame_tree.cc b/content/browser/frame_host/traced_frame_tree.cc
new file mode 100644
index 0000000000000000000000000000000000000000..18784b6702498d808364ef514ba35022953b4fcd
--- /dev/null
+++ b/content/browser/frame_host/traced_frame_tree.cc
@@ -0,0 +1,77 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "content/browser/frame_host/traced_frame_tree.h"
+
+#include "base/command_line.h"
+#include "base/json/json_writer.h"
+#include "content/browser/frame_host/frame_tree.h"
+#include "content/public/common/content_switches.h"
+
+namespace content {
+
+namespace {
+
+base::DictionaryValue* GetFrameTreeNodeAsValue(FrameTreeNode* node) {
+  base::DictionaryValue* value = new base::DictionaryValue();
+  value->SetString("url", node->current_url().spec());
+  value->SetInteger("ftid", node->frame_tree_node_id());

[nasko, 2015/10/26 15:59:23]

"ftnid" or even "ftn_id" or "ftnId", depending on which style is used in the
consumer of this JSON value.

+
+  RenderFrameHostManager* render_manager = node->render_manager();
+  RenderFrameHostImpl* current_frame_host =
+      render_manager->current_frame_host();
+  if (current_frame_host) {
+    value->SetInteger("cpid", current_frame_host->GetProcess()->GetID());

[nasko, 2015/10/26 15:59:23]

Why not "procId" and "routeId"? I find those a lot more readable and meaningful.
The "c" for current doesn't make much difference, as this isn't something people
outside of this code should care about.

+    value->SetInteger("crid", current_frame_host->GetRoutingID());
+  }
+
+  if (base::CommandLine::ForCurrentProcess()->HasSwitch(

[nasko, 2015/10/26 15:59:23]

I do not think the pending and speculative RFHs need to be included. I would
suggest removing this code unless there is a very compelling reason do have it.

[clamy, 2015/10/26 17:54:03]

I think it depends on what this code is supposed to be used for. If we want
precise association between RFH events and FTNs, ignoring the
speculative/pending RFH will mean that a bunch of events such as
DidStartProvisionalLoad may not get associated with the right FTN. It would be
nice to have more details about the planned use case for the tracing of
FrameTrees.

+          switches::kEnableBrowserSideNavigation)) {
+    RenderFrameHostImpl* speculative_frame_host =
+        render_manager->speculative_frame_host();
+    if (speculative_frame_host) {
+      value->SetInteger("spid", speculative_frame_host->GetProcess()->GetID());
+      value->SetInteger("srid", speculative_frame_host->GetRoutingID());
+    }
+  } else {
+    RenderFrameHostImpl* pending_frame_host =
+        render_manager->pending_frame_host();
+    if (pending_frame_host) {
+      value->SetInteger("ppid", pending_frame_host->GetProcess()->GetID());
+      value->SetInteger("prid", pending_frame_host->GetRoutingID());
+    }
+  }
+
+  if (node->child_count() != 0) {
+    scoped_ptr<base::ListValue> subframes(new base::ListValue());
+    for (size_t i = 0; i < node->child_count(); ++i) {
+      subframes->Append(GetFrameTreeNodeAsValue(node->child_at(i)));
+    }
+    value->Set("subframes", subframes.Pass());
+  }
+  return value;
+}
+
+}  // namespace
+
+scoped_refptr<TracedFrameTree> TracedFrameTree::Create(const FrameTree& tree) {
+  return scoped_refptr<TracedFrameTree>(new TracedFrameTree(tree));
+}
+
+TracedFrameTree::TracedFrameTree(const FrameTree& tree)
+    : tree_(tree) {
+}
+
+TracedFrameTree::~TracedFrameTree() {
+}
+
+void TracedFrameTree::AppendAsTraceFormat(std::string* out) const {
+  scoped_ptr<base::DictionaryValue> value(
+      GetFrameTreeNodeAsValue(tree_.root()));
+  std::string tmp;
+  base::JSONWriter::Write(*value, &tmp);
+  *out += tmp;
+}
+
+}  // content