In most cases a single RT entry corresponds to a single completed fetch (successful or non-aborted network error).
However, in the case of iframes this is a bit murky, especially when the iframes are cross-origin.

Imagine the following scenario (as represented in this test):

• embedder.com embeds crossorigin.com/iframe.html
• Before iframe.html's body fully loads, it navigates away to other.com/other-iframe.html - either by user interaction or by e.g. location.href setting in the head. (there are many ways in which this can happen)
• The iframe successfully loads other.com/other-iframe.html
• What should the resource timing entry correspond to?

Currently the resource timing entry (at least in chrome & Safari) would be of crossorigin.com, representing whatever state the response was when it was aborted. The entry would only be reported when the body of other.com is complete. According to spec perhaps it shouldn't be reported at all since it's an aborted fetch.

Both cases could lead to confusion and would be a cross-origin violation.
embedder.com is not supposed to know that the iframe has aborted and navigated to somewhere else, and both not reporting it at all or reporting the first navigation only would expose that.

One way to solve it is to align the timing with the timing of the iframe's load event, but that would be misleading - the time between navigating the iframe and the iframe's load event could be multiple fetches plus Javascript execution in the middle. Also, if we do this only for cross-origin iframes, they would diverge from what those timing values mean for same-origin iframes.

My proposal is to not report iframe navigation to resource timing at all, and to rely on navigation timing alone for this, letting the iframe explicitly send it information to the parent with postMessage if it so wishes. But I'm not sure the impact on current users of these APIs etc, so would love to hear thoughts.