[Webkit-unassigned] [Bug 168706] New: [Resource Timing] Clarify relationship between CachedResourceLoader and ResourceTimingInformation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=168706

            Bug ID: 168706
           Summary: [Resource Timing] Clarify relationship between
                    CachedResourceLoader and ResourceTimingInformation
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: joepeck at webkit.org
                CC: joepeck at webkit.org

[Resource Timing] Clarify relationship between CachedResourceLoader and ResourceTimingInformation

The existing code doesn't make sense.

CachedResources are put into the map but never taken out. This would be fine if CachedResources lifetime lasted as long as the page, but they can go away and their addresses can get reused. This means that having a table entry with a previous CachedResource address will prevent future CachedResources allocated at the same address from being reported. There doesn't appear to be a security issue since the address is all that is used as the key, the pointer itself is not used for anything. Another drawback of this is that the table will incur slight growth as more resources are requested even though the entry is no longer relevant.

The real question that needs to be answered here is what is the purpose of ResourceTimingInformation, and what is its relationship to CachedResourceLoader?

It seems to me as if the purpose right now is to:

  (1) Prevent duplicate PerformanceResourceTiming entries for the same CachedResource
  (2) Ensure we use the initiatorName for the first initiator that requested the resource

It would seem that we should be adding/removing entries as long as the CachedResourceLoader owns the CachedResource (see setOwningCachedResourceLoader). Because while owning the Resource is the extent of the time that the resource is known to the CachedResourceLoader. I don't yet know enough about CachedResource to know if this makes sense across multiple frames (same origin and cross origin).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170222/96f50e82/attachment.html>