Bug 157669 - ResourceTiming entries for cached resources and XHR
Summary: ResourceTiming entries for cached resources and XHR
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 157259 (view as bug list)
Depends on: 157796
Blocks:
  Show dependency treegraph
 
Reported: 2016-05-13 02:02 PDT by Yoav Weiss
Modified: 2017-02-10 12:09 PST (History)
3 users (show)

See Also:


Attachments
Patch (25.96 KB, patch)
2016-05-13 02:36 PDT, Yoav Weiss
no flags Details | Formatted Diff | Diff
Patch (26.07 KB, patch)
2016-05-13 04:07 PDT, Yoav Weiss
no flags Details | Formatted Diff | Diff
Patch (26.07 KB, patch)
2016-05-13 04:13 PDT, Yoav Weiss
no flags Details | Formatted Diff | Diff
Patch (25.57 KB, patch)
2016-05-13 13:12 PDT, Yoav Weiss
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yoav Weiss 2016-05-13 02:02:31 PDT
ResourceTiming entries for cached resources and XHR
Comment 1 Yoav Weiss 2016-05-13 02:36:42 PDT
Created attachment 278827 [details]
Patch
Comment 2 Yoav Weiss 2016-05-13 04:07:35 PDT
Created attachment 278831 [details]
Patch
Comment 3 Yoav Weiss 2016-05-13 04:13:53 PDT
Created attachment 278832 [details]
Patch
Comment 4 Yoav Weiss 2016-05-13 04:19:11 PDT
This fixes a few issues with ResourceTiming that were preventing it from being useful:
* Resources that were being reused from MemoryCache were not getting their own entries. 
* XHR based resources were not being registered.

The patch also splits out the resource timing entry registration logic from CachedResourceLoader into its own class.
Comment 5 Alex Christensen 2016-05-13 10:43:15 PDT
Comment on attachment 278832 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=278832&action=review

> Source/WebCore/loader/ResourceTimingInformation.cpp:14
> + *     * Neither the name of Google Inc. nor the names of its

I'm not sure this is the correct copyright.

> Source/WebCore/loader/ResourceTimingInformation.cpp:57
> +                initiatorDocument = document->parentDocument();

What if there are deeply nested iframes?  Should this be topDocument()?

> Source/WebCore/loader/ResourceTimingInformation.h:32
> +#ifndef ResourceTimingInformation_h
> +#define ResourceTimingInformation_h

#pragma once is the latest thing in WebKit.
Comment 6 Yoav Weiss 2016-05-13 13:12:06 PDT
Created attachment 278864 [details]
Patch
Comment 7 Yoav Weiss 2016-05-13 13:14:38 PDT
(In reply to comment #5)
> Comment on attachment 278832 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=278832&action=review
> 
> > Source/WebCore/loader/ResourceTimingInformation.cpp:14
> > + *     * Neither the name of Google Inc. nor the names of its
> 
> I'm not sure this is the correct copyright.

Indeed! Corrected

> 
> > Source/WebCore/loader/ResourceTimingInformation.cpp:57
> > +                initiatorDocument = document->parentDocument();
> 
> What if there are deeply nested iframes?  Should this be topDocument()?

I believe each iframe is reported as a resource in its parent document, so the above should by correct. FWIW, I didn't change the existing logic but just moved it from CachedResourceLoader to here.

> 
> > Source/WebCore/loader/ResourceTimingInformation.h:32
> > +#ifndef ResourceTimingInformation_h
> > +#define ResourceTimingInformation_h
> 
> #pragma once is the latest thing in WebKit.

Neat! Changed
Comment 8 Yoav Weiss 2016-05-13 15:11:47 PDT
Comment on attachment 278864 [details]
Patch

Thanks for reviewing! :)
Comment 9 WebKit Commit Bot 2016-05-13 15:33:37 PDT
Comment on attachment 278864 [details]
Patch

Clearing flags on attachment: 278864

Committed r200887: <http://trac.webkit.org/changeset/200887>
Comment 10 WebKit Commit Bot 2016-05-13 15:33:42 PDT
All reviewed patches have been landed.  Closing bug.
Comment 11 Joseph Pecoraro 2017-02-10 12:09:56 PST
*** Bug 157259 has been marked as a duplicate of this bug. ***