Now that we support audio, we can start correctly reporting we support
certain audio mime types!
Required by certain sites like Gartic Phone, which fails to load audio
because we didn't return a non-empty string for `audio/mpeg`:
```
"https://garticphone.com/sounds/turnundefined", Error: Load failed: 404
```
```js
(new Audio).canPlayType("audio/mpeg") && (this._extension = ".mp3"),
```
It can take some time to download / decode a media resource. During this
time, its duration is set to NaN. The media control box would then have
some odd rendering glitches as it tried to treat NaN as an actual time.
Once we do have a duration, we also must ensure the media control box is
updated.
Now that the processResponseConsumeBody algorithm receives the internal
response body of the fetched object, we do not need to go out of our way
to read its body from outside of fetch.
However, several elements do still need to manually inspect the internal
response for other data, such as response headers and status. Note that
HTMLScriptElement already does the new workaround as a proper spec step.
That's what this class really is; in fact that's what the first line of
the comment says it is.
This commit does not rename the main files, since those will contain
other time-related classes in a little bit.
Rather than queueing microtasks ad nauseam to check if a media element
has a new source candidate, let the media element tell us when it might
have a new child to inspect. This removes endless CPU churn in cases
where there is never a candidate that we can play.
Rather than setting the src attribute on the HTMLMediaElement, websites
may append a list of HTMLSourceElement nodes to the media element. There
is a series of "try the next source" steps to attempt to fetch/load each
source until we find one that works.
After the EventLoop changes, we do not need to override LibVideo's timer
with a Qt timer for Ladybird. The timer callback provided here also does
not need the JS::SafeFunction wrapper that Platform::Timer provides.
We are currently using the fetch controller's terminate() method to stop
ongoing fetches when the HTMLMediaElement load algorithm is invoked.
This method ultimately causes the fetch response to be a network error,
which we propagate through the HTMLMediaElement's error event. This can
cause websites, such as Steam, to avoid attempting to play any video.
The spec does not actually specify what it means to "stop" or "cancel" a
fetching process. But we should not use terminate() as that is a defined
spec method, and the spec does tend to indicate when that method should
be used (e.g. as it does in XMLHttpRequest).
We currently use Time::to_seconds() to report a video's duration. The
video, however, may have a sub-second duration. For example, the video
used by the video test page is 12.05 seconds long.
This has several advantages over the current manual demuxing currently
being performed. PlaybackManager hides the specific demuxer being used,
which will allow more codecs to be added transparently to LibWeb. It
also provides buffering and controls playback rate for us.
Further, it will allow us to much more easily implement the "media
timeline" to render a timestamp and implement seeking.
Note that the default value of the attribute is true. We were previously
autoplaying videos as soon as they loaded - this will prevent that from
happening until the paused attribute is set to false.
This ports MouseEvent, UIEvent, WheelEvent, and Event to new String.
They all had a dependency to T::create() in
WebDriverConnection::fire_an_event() and therefore had to be ported in
the same commit.
It's not totally clear to me when all of these states are supposed to be
set. For example, nothing in the HTMLMediaElement spec says to "set the
readyState attribute to HAVE_ENOUGH_DATA". However, this will at least
advance the readyState to HAVE_METADATA, which is needed for other
useful attributes for debugging.
