Add serializers for window.performance.

third_party/WebKit/Source/core/timing/Performance.cpp

Index: third_party/WebKit/Source/core/timing/Performance.cpp
diff --git a/third_party/WebKit/Source/core/timing/Performance.cpp b/third_party/WebKit/Source/core/timing/Performance.cpp
index e889ac82cefa28884970f236afa537ae4f8bd814..0555d69ee4999dbb46ec342f5811af361ab96604 100644
--- a/third_party/WebKit/Source/core/timing/Performance.cpp
+++ b/third_party/WebKit/Source/core/timing/Performance.cpp
@@ -31,6 +31,8 @@
 
 #include "core/timing/Performance.h"
 
+#include "bindings/core/v8/ScriptValue.h"
+#include "bindings/core/v8/V8ObjectBuilder.h"
 #include "core/dom/Document.h"
 #include "core/frame/LocalFrame.h"
 #include "core/inspector/InspectedFrames.h"
@@ -99,6 +101,14 @@ void Performance::updateLongTaskInstrumentation() {
   }
 }
 
+ScriptValue Performance::toJSONForBinding(ScriptState* scriptState) {
+  V8ObjectBuilder result(scriptState);
+  result.add("timing", timing()->toJSONForBinding(scriptState));
+  result.add("navigation", navigation()->toJSONForBinding(scriptState));
+  result.add("memory", memory()->toJSONForBinding(scriptState));

[martijnc, 2016/10/17 15:40:12]

Would it be better to ignore performance.memory for the serialization because it
is a non-standard API?

[foolip, 2016/10/18 10:28:00]

Good question. I think it depends on what we hope will happen to
performance.memory. If it's plausibly on a track to be implemented elsewhere,
then keeping it out here doesn't seem useful, but if we want to get rid of it
then spreading it around can make it *very slightly* harder to remove.

Will add Ilya.

+  return result.scriptValue();
+}
+
 DEFINE_TRACE(Performance) {
   visitor->trace(m_navigation);
   visitor->trace(m_timing);