1613140 - transferSize on PerformanceNavigationTiming is not available till after window.onload

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Abhishek Ghosh]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

Steps to reproduce:

Tried to obtain the values for transferSize, encodedBodySize and decodedBodySize values for the main document request ("navigation" resource) on DOMContentLoaded and window.load

Demo: https://8gbhu.csb.app/

Actual results:

It seems that the transferSize, encodedBodySize and decodedBodySize values for the main document request ("navigation") is not available till after an async function call after window.onload and incorrectly reports as 0 on events like DOMContentLoaded and window.onload

This is a bit unexpected since intuitively transferSize should have been available as soon as the responseEnd for the main document request was complete. That is also my limited understanding from the spec: https://www.w3.org/TR/resource-timing-2/#sec-process (see point 19.2).

Expected results:

I'm curious why aren't the values available sooner?

transferSize and associated values for the main document navigation resource should have been available right after the response for the main document, such that it can be accessed correctly on events like DOMContentLoaded.

As a side-note/comparison, Chromium seems to exhibit this behaviour.

Comment 1

[Abhishek Ghosh]

Although I filed this on Bugzilla from this UA (Chrome, mentioned above): Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36, the actual bug is reproducible on this UA (Firefox): Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:72.0) Gecko/20100101 Firefox/72.0

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

baku: Could you take a look or redirect this ni to proper person?

Comment 3

[Valentin Gosu [:valentin] (he/him)]

So, the attributes are updated via the following calls:

PerformanceNavigationTiming::UpdatePropertiesFromHttpChannel -> PerformanceMainThread::QueueNavigationTimingEntry -> nsPIDOMWindowInner::QueuePerformanceNavigationTiming -> nsDocumentViewer::LoadComplete -> nsDocShell::EndPageLoad -> nsDocShell::OnStateChange

However, the onload handlers are sent from Document::EndLoad - I think it might make sense to call nsPIDOMWindowInner::QueuePerformanceNavigationTiming from there, but I'm not super sure that it's the correct solution.
In any case, I'll submit the patch for review + WPT tests.

Comment 4

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1613140 - Call QueuePerformanceNavigationTiming from Document::EndLoad() r=baku

Comment 5

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1613140 - Add WPT that the size attributes for PerformanceNavigationTiming have been updated during DOMContentLoaded/onload r=baku

Depends on D62110

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e9172bdcb507
Call QueuePerformanceNavigationTiming from Document::EndLoad() r=baku
https://hg.mozilla.org/integration/autoland/rev/642b10191ecb
Add WPT that the size attributes for PerformanceNavigationTiming have been updated during DOMContentLoaded/onload r=baku

Comment 7

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/21725 for changes under testing/web-platform/tests

Comment 8

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 9

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/e9172bdcb507
https://hg.mozilla.org/mozilla-central/rev/642b10191ecb

Comment 10

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot