Pass DOMWinow to PerformanceLongTaskTiming for attribution

third_party/WebKit/Source/core/timing/PerformanceLongTaskTiming.h

Index: third_party/WebKit/Source/core/timing/PerformanceLongTaskTiming.h
diff --git a/third_party/WebKit/Source/core/timing/PerformanceLongTaskTiming.h b/third_party/WebKit/Source/core/timing/PerformanceLongTaskTiming.h
index 5c836d6334a98b5ac5b7e49534a276f12e6d6b7c..1ce88a2b72ae6049a28192d1345dd8482637df67 100644
--- a/third_party/WebKit/Source/core/timing/PerformanceLongTaskTiming.h
+++ b/third_party/WebKit/Source/core/timing/PerformanceLongTaskTiming.h
@@ -13,6 +13,7 @@
 namespace blink {
 
 class Document;
+class DOMWindow;
 
 class PerformanceLongTaskTiming final : public PerformanceEntry {
   DEFINE_WRAPPERTYPEINFO();
@@ -20,17 +21,24 @@ class PerformanceLongTaskTiming final : public PerformanceEntry {
  public:
   static PerformanceLongTaskTiming* create(double startTime,
                                            double endTime,
-                                           String frameContextUrl) {
-    return new PerformanceLongTaskTiming(startTime, endTime, frameContextUrl);
+                                           String name,
+                                           DOMWindow* culpritWindow) {
+    return new PerformanceLongTaskTiming(startTime, endTime, name,
+                                         culpritWindow);
   }
 
+  DOMWindow* culpritWindow() const;
+
   DECLARE_VIRTUAL_TRACE();
 
  private:
   PerformanceLongTaskTiming(double startTime,
                             double endTime,
-                            String frameContextUrl);
+                            String name,
+                            DOMWindow* culpritWindow);
   ~PerformanceLongTaskTiming() override;
+
+  Member<DOMWindow> m_culpritWindow;

[dgozman, 2016/10/05 01:21:39]

Are we concerned about this entry retaining DOMWindow? How long does it live? Do
other entries retain something heavy?

[panicker, 2016/10/05 04:11:31]

This is a good question, and we did discuss it a fair bit.
Currently the performance implication is not significant, as there is no buffer
being maintained (see https://codereview.chromium.org/2395653002) )we deliver
the entries - right away, triggered by short periodic timer.
(Other Performance Entries like Resource Timing do maintain buffers, but they
don't typically retain anything heavy)

Secondly, this is likely not the final shape of the API, but we wanted to make
the DOMWindow available in the Origin Trial to 
give developers the best opportunity to identify the culprit frame.

Going forward (beyond Origin Trial limited to 0.03% of chrome page loads) we
should definitely measure and determine whether there is a non-trivial
performance implication, if there is interest in adding this to the spec.
 

 };
 
 }  // namespace blink