Closed Bug 2015583 Opened 1 month ago Closed 1 month ago

Fix `stalled` events not being dispatched correctly on Firefox for certain WPTs

Categories

(Core :: Audio/Video: Playback, task, P2)

task

Tracking

()

RESOLVED FIXED
149 Branch
Tracking Status
firefox149 --- fixed

People

(Reporter: alwu, Assigned: alwu)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 1 obsolete file)

Some WPTs expect a media element to receive a stalled event, but the current test implementations are incorrect and cannot produce the expected results in Firefox. This issue affects tests such as:

We should fix those wpt and ensure the solution remains compatible with other brows

Reduce the initial data burst sent by stall-resume.py from ~156KB
(file_size / 30) to 4096 bytes. Browsers apply preload heuristics and
stop requesting more data from the server once they have buffered enough
to satisfy those heuristics. If the initial burst is too large, the browser
suspends the channel before entering the stall condition, so the stalled
event never fires. Keeping the initial burst small ensures browsers stay in
the loading state and trigger the stalled event after the expected timeout.

The previous tests used a trickle pipe URL to trigger the stalled event,
which was unreliable and caused timeouts. This patch switches the tests to
use stall-resume.py, which sends an initial burst of data then stalls
indefinitely until a POST request resumes delivery. This approach works
reliably across all major browsers (Firefox, Chrome, Safari) that dispatch
the stalled event after a period without new data during active playback.

The test files are also renamed from .html to .sub.html to enable WPT
server-side substitution, which allows {{uuid()}} to generate a unique
stash key per test run without requiring JavaScript UUID generation or a
secure context.

Remove the TIMEOUT/NOTRUN expectations from the INI files now that the tests
pass reliably. The invalidation test retains the
dom.media.pseudo-classes.enabled pref since that feature is still behind a
flag in Firefox.

:stalled requires readyState <= HAVE_CURRENT_DATA (indicated by the waiting
event) and networkState == NETWORK_LOADING in a stalled state (indicated by
the stalled event, which fires after is currently stalled is set per
https://github.com/whatwg/html/pull/11959). The original test only checked
:stalled in the stalled event handler, where readyState may still be
HAVE_FUTURE_DATA if the browser buffered ahead, causing the assertion to fail.

Fix by awaiting both events with Promise.all before asserting :stalled, and
update the post-resume check to use timeupdate instead of progress.

Attachment #9546316 - Attachment description: Bug 2015583 - part4 : Fix media-loading-state-timing.sub.html to await both waiting and stalled events → Bug 2015583 - part3 : Fix media-loading-state-timing.sub.html to await both waiting and stalled events
Attachment #9546315 - Attachment is obsolete: true
Pushed by alwu@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/4edbc2c0c312 https://hg.mozilla.org/integration/autoland/rev/8d3baf8da8f9 part1 : Reduce initial burst in stall-resume.py to prevent channel suspension r=padenot https://github.com/mozilla-firefox/firefox/commit/651c8a282e72 https://hg.mozilla.org/integration/autoland/rev/c22c18a22db7 part2 : Switch WPT media loading pseudo-class tests to use stall-resume.py r=padenot https://github.com/mozilla-firefox/firefox/commit/ca0e58964e86 https://hg.mozilla.org/integration/autoland/rev/6ed5c77ff4f8 part3 : Fix media-loading-state-timing.sub.html to await both waiting and stalled events r=padenot
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/57949 for changes under testing/web-platform/tests
QA Whiteboard: [qa-triage-done-c150/b149]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: