Open emilio opened 4 years ago
Thanks for catching that. I don't think there are such guarantees. Seems like we'd need to rewrite these using PerformanceObserver (under the assumption that entries delivered to the observer were similarly delivered to the Performance Timeline).
/cc @npm1
The spec is not very clear about this, as the processing model is written as if everything happens synchronously but it does not because it depends on the fetch result. I think it's fine for entries to be dispatched async, and we should modify the tests. PR is welcome, otherwise we can take a stab at it as part of the WebPerf hackathon which is happening Tuesdays for a couple of weeks!
I tried to fix this and realized that the tests rely on sync XHR for a reason.
All the tests that still use syncXHR
after https://github.com/web-platform-tests/wpt/pull/25673 are testing what happens when buffering entries that are added while the buffer is full and before the resourcetimingbufferfull
event is done.
Adding asynchronicity to those tests results in the event running in points where we don't want it to run, so we're not testing what needs to be tested. I removed dependence on sync addition of entries from other places where it was possible without making the test useless.
And I don't think that's guaranteed?
All the callers of
xhrScript
seem to rely on the entry being available synchronously, which doesn't happen in Firefox's implementation and I don't think is guaranteed by the spec unless I'm missing something.@yoavweiss you seemed to introduce these, do you know what would guarantee that that entry is available synchronously?