1509754 - Consider to lower the priority of async XHR and fetch() while the page is loading

Status: NEW

(Core :: DOM: Networking, enhancement, P3)

Description

[Olli Pettay [:smaug][[e-mail]]]

XHR and fetch() don't block load event to fire, at least not by default.
(XHR with progress events listeners does block load event - that is an implementation limitation/detail).
So, if they don't block load event, better to ensure we process them after stuff which need be loaded before load event.
Now - I can't recall if BACKGROUND requests are automatically processed after non-BACKGROUND. If that is the case, then this is invalid.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

I don't see anything BACKGROUND related in Necko when it schedules based on priority, so yeah, looks like this is something to investigate some more.


And a link for myself to remind where some related code is
https://searchfox.org/mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9/netwerk/protocol/http/nsHttpConnectionMgr.cpp#73-108

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Also https://searchfox.org/mozilla-central/source/netwerk/base/nsIClassOfService.idl if we don't want to use priorities.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

If I read the code correctly, we end up processing not-load-blocking-XHR/fetch before iframes :/

https://searchfox.org/mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9/docshell/base/nsDocShell.cpp#2783-2787

Comment 4

[Honza Bambas (:mayhemer)]

Setting lower priority on a request (which means to give it a larger number as a priority value [1]) re-schedules only in the scope of [origin, origin attributes, anonymity].  If you want to scope for the whole page load, set Tail and remove Unblocked [2] service class flags.  Unblocked is set on xhr at [3].  The reason to set Unblock and never force tailing on xhr was that we have found cases when e.g. a css load (=Leader, which blocks everything else except Unblocked) was blocked on an xhr request that was sniffing some browser properties first via a script.  So, be careful with rescheduling or blocking early xhr scripts for too long, those may very well influence perf badly by effecting such dependencies and even cause breakage.

[1] https://searchfox.org/mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9/xpcom/threads/nsISupportsPriority.idl#24-28
[2] https://searchfox.org/mozilla-central/source/netwerk/base/nsIClassOfService.idl#44,48-50
[3] https://searchfox.org/mozilla-central/rev/f997bd6bbfc4773e774fdb6cd010142370d186f9/dom/xhr/XMLHttpRequestMainThread.cpp#2654

Comment 5

[Junior [inactive]]

I'm doing the triage but not sure what the importance this is.
Could you please set the priority for this bug, smaug?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

I think this as part of the page load work performance team is doing. So as of now this is still on performance team's plate I think. Not sure about priority (I don't know how necko team uses priorities).
(In DOM I would say this is P3, based on https://mzl.la/2JtE4IH )