ladybird/Tests/LibWeb/Text/input/HTML/HTMLMediaElement-load-after-decode-error.html

<!DOCTYPE html>
<script src="../include.js"></script>
<script src="HTMLMediaElement-include.js"></script>
<video id="video"></video>
<script>
    const video = document.getElementById("video");

    function logEvent(name) {
        let entry = `${name}: ${formatReadyStateExpectation(video, name)}`;
        if (name === "durationchange")
            entry += ` duration=${video.duration}`;
        if (name === "error")
            entry += ` code=${video.error.code}`;
        println(entry);
    }

    for (const name of [
        "loadstart", "abort", "error", "emptied",
        "loadedmetadata", "durationchange", "ended",
    ]) {
        video.addEventListener(name, () => logEvent(name));
    }

    asyncTest(async done => {
        video.src = "../../../Assets/corrupt-video.webm";

        await new Promise(resolve => video.addEventListener("error", resolve, { once: true }));
        video.src = "../../../Assets/test-webm.webm";

        await new Promise(resolve => video.addEventListener("canplaythrough", resolve, { once: true }));
        done();
    });
</script>
LibWeb: Prevent a crash when triggering media load in the error handler If we fire the error event synchronously within the on_error callback, then we'll end up destroying the PlaybackManager inside its own callback and crash. Instead, queue a task to execute the error steps. This could happen with or without MSE, but I observed it occurring on YouTube with MSE when we hit a decoding error, since they immediately try another source when an error is reported. 2026-03-31 17:08:48 -03:00			`<!DOCTYPE html>`
			`<script src="../include.js"></script>`
Tests: Stop worrying about exact media element ready states in events Instead, just verify a minimum for each event. Ready states aren't deterministic when following spec anyway. 2026-05-12 22:54:53 -03:00			`<script src="HTMLMediaElement-include.js"></script>`
LibWeb: Prevent a crash when triggering media load in the error handler If we fire the error event synchronously within the on_error callback, then we'll end up destroying the PlaybackManager inside its own callback and crash. Instead, queue a task to execute the error steps. This could happen with or without MSE, but I observed it occurring on YouTube with MSE when we hit a decoding error, since they immediately try another source when an error is reported. 2026-03-31 17:08:48 -03:00			`<video id="video"></video>`
			`<script>`
			`const video = document.getElementById("video");`

			`function logEvent(name) {`
Tests: Stop worrying about exact media element ready states in events Instead, just verify a minimum for each event. Ready states aren't deterministic when following spec anyway. 2026-05-12 22:54:53 -03:00			let entry = `${name}: ${formatReadyStateExpectation(video, name)}`;
LibWeb: Prevent a crash when triggering media load in the error handler If we fire the error event synchronously within the on_error callback, then we'll end up destroying the PlaybackManager inside its own callback and crash. Instead, queue a task to execute the error steps. This could happen with or without MSE, but I observed it occurring on YouTube with MSE when we hit a decoding error, since they immediately try another source when an error is reported. 2026-03-31 17:08:48 -03:00			`if (name === "durationchange")`
			entry += ` duration=${video.duration}`;
			`if (name === "error")`
			entry += ` code=${video.error.code}`;
Tests: Simplify the HTMLMediaElement-load-after-decode-error.html test Use promises to await the expected sequence of events. Also, don't assume that canplaythrough will fire after error. That depends on the implementation. 2026-04-06 18:35:29 -03:00			`println(entry);`
LibWeb: Prevent a crash when triggering media load in the error handler If we fire the error event synchronously within the on_error callback, then we'll end up destroying the PlaybackManager inside its own callback and crash. Instead, queue a task to execute the error steps. This could happen with or without MSE, but I observed it occurring on YouTube with MSE when we hit a decoding error, since they immediately try another source when an error is reported. 2026-03-31 17:08:48 -03:00			`}`

			`for (const name of [`
			`"loadstart", "abort", "error", "emptied",`
Tests: Stop worrying about exact media element ready states in events Instead, just verify a minimum for each event. Ready states aren't deterministic when following spec anyway. 2026-05-12 22:54:53 -03:00			`"loadedmetadata", "durationchange", "ended",`
LibWeb: Prevent a crash when triggering media load in the error handler If we fire the error event synchronously within the on_error callback, then we'll end up destroying the PlaybackManager inside its own callback and crash. Instead, queue a task to execute the error steps. This could happen with or without MSE, but I observed it occurring on YouTube with MSE when we hit a decoding error, since they immediately try another source when an error is reported. 2026-03-31 17:08:48 -03:00			`]) {`
			`video.addEventListener(name, () => logEvent(name));`
			`}`

Tests: Simplify the HTMLMediaElement-load-after-decode-error.html test Use promises to await the expected sequence of events. Also, don't assume that canplaythrough will fire after error. That depends on the implementation. 2026-04-06 18:35:29 -03:00			`asyncTest(async done => {`
			`video.src = "../../../Assets/corrupt-video.webm";`
LibWeb: Prevent a crash when triggering media load in the error handler If we fire the error event synchronously within the on_error callback, then we'll end up destroying the PlaybackManager inside its own callback and crash. Instead, queue a task to execute the error steps. This could happen with or without MSE, but I observed it occurring on YouTube with MSE when we hit a decoding error, since they immediately try another source when an error is reported. 2026-03-31 17:08:48 -03:00
Tests: Simplify the HTMLMediaElement-load-after-decode-error.html test Use promises to await the expected sequence of events. Also, don't assume that canplaythrough will fire after error. That depends on the implementation. 2026-04-06 18:35:29 -03:00			`await new Promise(resolve => video.addEventListener("error", resolve, { once: true }));`
			`video.src = "../../../Assets/test-webm.webm";`
LibWeb: Prevent a crash when triggering media load in the error handler If we fire the error event synchronously within the on_error callback, then we'll end up destroying the PlaybackManager inside its own callback and crash. Instead, queue a task to execute the error steps. This could happen with or without MSE, but I observed it occurring on YouTube with MSE when we hit a decoding error, since they immediately try another source when an error is reported. 2026-03-31 17:08:48 -03:00
Tests: Simplify the HTMLMediaElement-load-after-decode-error.html test Use promises to await the expected sequence of events. Also, don't assume that canplaythrough will fire after error. That depends on the implementation. 2026-04-06 18:35:29 -03:00			`await new Promise(resolve => video.addEventListener("canplaythrough", resolve, { once: true }));`
			`done();`
LibWeb: Prevent a crash when triggering media load in the error handler If we fire the error event synchronously within the on_error callback, then we'll end up destroying the PlaybackManager inside its own callback and crash. Instead, queue a task to execute the error steps. This could happen with or without MSE, but I observed it occurring on YouTube with MSE when we hit a decoding error, since they immediately try another source when an error is reported. 2026-03-31 17:08:48 -03:00			`});`
			`</script>`