2046419 - XMLHttpRequest with progress event listener blocks the load event

Status: RESOLVED FIXED

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

Description

[Holger Benl [:hbenl]]

This Playwright test started permafailing on 2026-05-27, the test hangs at await page.goto(server.EMPTY_PAGE); because Playwright waits for browsingContext.load which is never sent by Firefox.
The XMLHttpRequest blocks the load DOM event in Firefox and this patch flipped the dom.timeout.defer_during_load pref to false which is why this started failing.

I've verified that

• the test also fails with Juggler if I set that pref to false in the Playwright config
• without the setTimeout() wrapper around the XMLHttpRequest the test fails (with both Juggler and BiDi but not in other browsers) even if dom.timeout.defer_during_load is set to true

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:emilio, since you are the author of the regressor, bug 2017786, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

My patch changed the relative order between load and the timeout function, but to be clear this is not about the DOM load event right? https://crisal.io/tmp/slow-fetch.html shows the expected behavior (not blocking the load event).

So this is more about the BiDi side of things aiui... right?

Comment 3

[Holger Benl [:hbenl]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #2)

My patch changed the relative order between load and the timeout function, but to be clear this is not about the DOM load event right? https://crisal.io/tmp/slow-fetch.html shows the expected behavior (not blocking the load event).

Try attaching an onprogress listener like in the Playwright test. When I change that test to not attach an onprogress listener then it works too. So this seems specifically related to that listener.

So this is more about the BiDi side of things aiui... right?

I don't think so, with onprogress I can get the DOM load event to be blocked.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Weird, I wasn't expecting this to depend on an event listener...

Comment 5

[Emilio Cobos Álvarez [:emilio]]

(It does, of course: https://searchfox.org/firefox-main/rev/8e16ea8e5df0354144902ae0911a5609344bdb6d/dom/xhr/XMLHttpRequestMainThread.cpp#2761-2772)

This is, let's say... not exactly a recent regression. Goes all the way back to the original implementation of the progress event o.O

Comment 6

[Emilio Cobos Álvarez [:emilio]]

I took a look, and I don't think that claim is true (anymore?). This was introduced in bug 251418...

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2046419 - Don't use LOAD_NORMAL for XHRs with progress event listeners. r=smaug

It has the side effect of blocking the load event, and its claim is no
longer true. Progress notifications from necko are not conditional on
LOAD_BACKGROUND anymore.

FWIW I did the digging on when that claim stopped being true, it seems
it was in bug 1007020 /
https://hg.mozilla.org/mozilla-central/rev/572492b2e400, which has a
commit with title:

Also send progress information when connection is LOAD_BACKGROUND.

OnStatus is actually conditional on LOAD_BACKGROUND but XHR only uses it
to forward to the original channel listener. So not an issue I don't
think.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/060bc28042ce
https://hg.mozilla.org/integration/autoland/rev/1b199f86d318
Don't use LOAD_NORMAL for XHRs with progress event listeners. r=smaug,search-reviewers,scunnane

Comment 9

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/1b199f86d318