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.)
