Rather than splitting the Iterator type and its AOs into two files,
let's combine them into one file to match every other JS runtime object
that we have.
This is an editorial change in the ECMA-262 spec. See:
956e5af
This splits the GetIterator AO into two AOs, to remove some recursion
and to (soon) remove optional parameters.
This does not implement extra functionality on top of the basic parser,
but allows multiple places in LibWeb to call the 'correct' interface for
when it is fully implemented.
Now that we use the HTML image loading algorithm from spec, we can
implement complete correctly.
This (finally) fixes an issue where images were not loading on
https://twinings.co.uk/ :^)
Since the underlying HTML::Window can change, caching property accesses
on WindowProxy is not as simple as remembering the shape. Let's disable
caching here for now. We can come back to it in the future when we have
no low-hanging fruit left. :^)
Fixes an assertion failure on https://twinings.co.uk/
This function now takes an optional out parameter for callers who would
like to what kind of property we ended up getting.
This will be used to implement inline caching for property lookups.
Also, to prepare for adding more forms of caching, the out parameter
is a struct CacheablePropertyMetadata rather than just an offset. :^)
The main missing features are rootMargin, proper nested browsing
context support and content clip/clip-path support.
This makes images appear on some sites, such as YouTube and
howstuffworks.com.
We've peppered this workaround around the code base as needed in a few
different ways. This adds a helper class to perform this workaround in
order to simplify doing so, and ensure cleanup occurs in a RAII fashion.
This also makes it easier to grep for places where this workaround is
employed.
This fixes an issue where a BOM at the head of a style sheet would be
passed verbatim to the parser, who would then interpret it as an ident
token and (after some confusion) fail to parse the first rule, but then
carry on with the rest of the sheet.
This allows increasing and decreasing the media volume by 10% with the
up and down arrow keys, respectively. This also allows toggling the mute
state with the M key.
This allows seeking backwards and forwards by 5 seconds with the left
and right arrow keys, respectively. This also allows seeking to the
beginning and end of the media track with the home and end keys.
Mostly seen on macOS, but when we toggle playing a media element, we
need to update its layout node's display to ensure the change is
reflected on the playback button. Further, when setting the element's
display time, we need to update the display to ensure the change is
refelected on the media timeline.
There were multiple bugs in the parsing algorithm for handling text
occurring inside a `table` element:
- When there was pending non-whitespace text inside a table, we only
flushed one token instead of all pending tokens.
- Also, we didn't even flush one of the right tokens, but instead the
token that caused the flush to happen.
- Once we started flushing the right tokens, it turned out we had not
yet implemented character insertion points expressed as "before X".
- Finally, we were not exiting the "in table text" mode after flushing
pending tokens, effectively getting us stuck in that mode until EOF.
In the merging of an extremely large navigables PR, a task queue source
was added after the unique task source start value that was supposed to
remain last in the enum.
Previously, an audio loader could succeed for an HTMLVideoElement that
contains a video file, which caused the duration to be set to the bogus
duration of the audio loader instead of the correct duration from the
video container. Instead of setting the duration based on audio always,
set it to the video duration if we are creating a video element.
This is only needed because currently spec doesn't explicitly define
that navigable should have a pointer to associated container and when
this pointer should be set.
The JS::VM now owns the one Bytecode::Interpreter. We no longer have
multiple bytecode interpreters, and there is no concept of a "current"
bytecode interpreter.
If you ask for VM::bytecode_interpreter_if_exists(), it will return null
if we're not running the program in "bytecode enabled" mode.
If you ask for VM::bytecode_interpreter(), it will return a bytecode
interpreter in all modes. This is used for situations where even the AST
interpreter switches to bytecode mode (generators, etc.)
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.
