Bug 242451 - Cross-Origin iFrames not adding PerformanceResourceTiming entry when it comes from cache
Summary: Cross-Origin iFrames not adding PerformanceResourceTiming entry when it comes...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: Safari 16
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-07-07 09:39 PDT by James Hartig
Modified: 2024-06-28 11:13 PDT (History)
6 users (show)

See Also:


Attachments
Safeframe embedded page (929 bytes, text/html)
2022-07-07 09:39 PDT, James Hartig
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Hartig 2022-07-07 09:39:05 PDT
Created attachment 460738 [details]
Safeframe embedded page

Cross-origin iFrames with Timing-Allow-Origin: * are not generating an PerformanceTimingEntry when the iframe comes from cache.

The code on https://jsbin.com/veyidigudi loads a safeframe and then adds the performance entry in a textNode after it. The first time you load it, there will be an entry but when you refresh the page the timing entry goes away. Clearing cache and refreshing brings the timing entry back until you refresh for the 4rd time (and it comes from cache again).
Comment 1 Radar WebKit Bug Importer 2022-07-14 09:40:18 PDT
<rdar://problem/97019263>
Comment 2 James Hartig 2022-12-20 08:30:00 PST
This is still an issue in Safari 16. Any update on this? Chrome 109 and Firefox 109 both have a entry present even when the iframe comes from cache.
Comment 3 Ahmad Saleem 2024-06-28 11:13:26 PDT
In WebKit ToT (280460@main) - it shows:

[ { "name": "https://tpc.googlesyndication.com/safeframe/1-0-37/html/container.html", "entryType": "resource", "startTime": 619, "duration": 61, "initiatorType": "iframe", "nextHopProtocol": "h2", "workerStart": 0, "redirectStart": 0, "redirectEnd": 0, "fetchStart": 619, "domainLookupStart": 620, "domainLookupEnd": 621, "connectStart": 622, "connectEnd": 654, "secureConnectionStart": 633, "requestStart": 654, "responseStart": 677, "responseEnd": 680, "transferSize": 0, "encodedBodySize": 0, "decodedBodySize": 0, "serverTiming": [] } ]

So I think it might have been fixed recently since even STP197 is broken.

@Youenn - something you fixed recently? https://github.com/WebKit/WebKit/commit/6a2c5a3042534caf2df6952d1d7d151d3e3c76bc