Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
The volume control's slider is drawn in a rectangle shrunken by its
slider handle's size, so the handle did not move 1:1 with the user's
mouse movement.
To fix this, it will now check for a mousedown in the volume control
with a rectangle sized to fit any possible position of the handle, but
the volume value result will be calculated based on the center of the
handle instead. This allows it to move 1:1 with the mouse cursor.
Co-authored-by: trflynn89 <trflynn89@serenityos.org>
This implements the ability to drag the timeline and volume buttons on
UA-rendered media controls. The two behave a bit differently:
Volume is updated as the user drags the volume button. This isn't a very
expensive operation, so updating in real-time and hearing the volume
change feels nice.
The current time, on the other hand, is not committed until the user
releases the mouse button. Performing a seek every time we get a mouse-
move event is pretty laggy, especially for video. However, we still want
to render updates on the timeline itself (so the position of the button
and the timestamp update as you drag). To do so, we internally pause the
media and override the timestamp provided to the layout node.
In the future, we may be able to seek video periodically to provide some
visual feedback. For example, we can seek after every N seconds of
scrubbing, or when the user pauses scrubbing for a while.
This moves the painting of the media timeout out of VideoPaintable into
a base MediaPaintable. This is to allow re-using the same timeline logic
and controls for audio elements.
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.
This will be needed by the layout node, which may change what is painted
when the position of the frame image is not the same as the element's
current time.
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.
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.
The spec for loading a media element is quite huge. This implements just
enough to parse the attribute, fetch the corresponding media object, and
decode the media object (if it is a video). While doing so, this also
implements most network state tracking and firing DOM events that may be
observed via JavaScript.
Note that as of this commit, there aren't any such throwers, and the
call site in Heap::allocate will drop exceptions on the floor. This
commit only serves to change the declaration of the overrides, make sure
they return an empty value, and to propagate OOM errors frm their base
initialize invocations.
