-
Notifications
You must be signed in to change notification settings - Fork 330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial resource timing integration. #1185
Conversation
"global" is a term already used to describe the global object, while this monotonic clock is shared across globals (e.g. workers and the window). Also expose "current universal time", for use by Fetch. See whatwg/fetch#1185
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would help a lot if you checked the final diff and read through it at least once to make sure there are no obvious mistakes there. At least I personally tend to spot a lot of mistakes when doing that in my own writing.
Overall I think this approach looks good. I'm a little worried about it also relying on the "done flag" badness. Perhaps the solution there is to accept that implementations are not full duplex and so once the response stream is closed it's really all over.
One thing I haven't done in detail is ensuring that the point of capture matches RT and matches implementations. For that it would be helpful to have some pointers to tests. As I also noted I would prefer to not define fields we're unsure of or that can be inferred from other fields.
(I also do not see transfer size, was that omitted intentionally?)
Sorry for that. I will double check next time.
Yes. |
7496b4a
to
d0e2408
Compare
See issue for adding connection tests: web-platform-tests/wpt#27935 |
e1a3e17
to
526a3d1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's still a lot of style issues left that I mostly tried to read over. I left some questions for things that are unclear. I checked some of the timings, but that could use another look as well. Is @yoavweiss also looking at those?
0538a2f
to
10cb532
Compare
I would like to see a test for a synthetic response from a service worker. Per the current set of definitions most fields would end up being 0, but is that what implementations do? Similarly, testing |
b19b46e
to
a96f625
Compare
903f911
to
b37ef51
Compare
Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
fetch.bs
Outdated
|
||
<li><p>If <var>timingInfo</var>'s <a for="fetch timing info">redirect start time</a> is not 0, then | ||
set <var>startTime</var> to <var>timingInfo</var>'s | ||
<a for="fetch timing info">redirect start time</a>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I missed this.
Why would we do this for the case where we cannot reveal information?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you're asking. The redirect start time
is not revealing, as it occurs before the first redirect and keeps all the redirect info obscure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But doesn't that reveal there was a redirect?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. It sets startTime
to be the redirect start time
, so it exposes a startTime
, and the caller doesn't know that its from a redirect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I do performance.now()
and then invoke fetch()
it seems I would be able to tell quite easily it's not the actual start time and instead something from the network.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
w3c/resource-timing#260 :)
This PR actually fixes that, as startTime
would mean redirectStart
, the time before the first redirect, and not fetchStart
, the time after the last redirect.
Commit message: Take note of the different timings required for the resource timing spec. The particular points where time is measured is based on the current Resource Timing spec, and the missing parts reflect current implementations:
Note that FETCH doesn't decide when to enqueue the resource timing entry, but rather creates the data structure that holds the different timings, and it's up to the caller to enqueue. FETCH sends a new event, It's the first phase for addressing w3c/resource-timing#252, which contains a link to the other required multi-repo steps to address RT/NT/HTML/Fetch integration. |
That description misses: |
Outstanding issues:
|
Not sure what you mean. when TAO isn't there we reset both fetch start time and start time, to avoid exposing the fact that there were redirects.
Right, it would capture that start of that fetch, as 401 is not exactly a redirect. It's more like a "post-redirect fetch start time".
OK. I don't mind the renames |
In https://whatpr.org/fetch/1185.html#finalize-and-report-timing step 5 we initialize startTime to fetch start time. At that point fetch start time is not guaranteed to be equal to start time, right? Then step 6 compensates for that. Then step 7 does the reset. But why not initialize startTime to start time and drop step 6? It seems that would be a lot clearer. I really like post-redirect fetch start time by the way, let's use that! Or maybe even post-redirect start time. No need to mention fetch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still LGTM
I like the new names, even if they diverge from the web exposed ones, as they are indeed more descriptive.
Create a "document load timing info" struct, associated with a document, which receives its information from several sources: - fetch timing of the navigation response - Load/DOMContentLoaded event dispatches - Document readyness state changes - sending unload events to the previous document, if it comes from the same origin. See w3c/navigation-timing#136 Depends on whatwg/fetch#1185
Create a "document load timing info" struct, associated with a document, which receives its information from several sources: - fetch timing of the navigation response - Load/DOMContentLoaded event dispatches - Document readyness state changes - sending unload events to the previous document, if it comes from the same origin. See w3c/navigation-timing#136 Depends on whatwg/fetch#1185
When response is a network error or body is fully read, finalize and report the response. Depends on whatwg/fetch#1185 See: w3c/resource-timing#261 and w3c/resource-timing#252
When response is a network error or body is fully read, finalize and report the response. Depends on whatwg/fetch#1185. Also see w3c/resource-timing#261 and w3c/resource-timing#252.
When response is a network error or body is fully read, finalize and report the response. Depends on whatwg/fetch#1185. Also see w3c/resource-timing#261 and w3c/resource-timing#252.
Created a "fetch timing info" struct to hold the bookkeeping necessary for resource timing.
Populated it with some of the required values, leaving some of them for later patches as this is a big undertaking.
See w3c/resource-timing#252
Preview | Diff