Currently, all handling of pending dialogs occurs in PageHost. In order
to re-use this functionality to run WebDriver in a headless move, move
it to Page.
Before this change, each AST node had a 64-byte SourceRange member.
This SourceRange had the following layout:
filename: StringView (16 bytes)
start: Position (24 bytes)
end: Position (24 bytes)
The Position structs have { line, column, offset }, all members size_t.
To reduce memory consumption, AST nodes now only store the following:
source_code: NonnullRefPtr<SourceCode> (8 bytes)
start_offset: u32 (4 bytes)
end_offset: u32 (4 bytes)
SourceCode is a new ref-counted data structure that keeps the filename
and original parsed source code in a single location, and all AST nodes
have a pointer to it.
The start_offset and end_offset can be turned into (line, column) when
necessary by calling SourceCode::range_from_offsets(). This will walk
the source code string and compute line/column numbers on the fly, so
it's not necessarily fast, but it should be rare since this information
is primarily used for diagnostics and exception stack traces.
With this, ASTNode shrinks from 80 bytes to 32 bytes. This gives us a
~23% reduction in memory usage when loading twitter.com/awesomekling
(330 MiB before, 253 MiB after!) :^)
We can't be nuking the ESO while its owned execution context is still on
the VM's execution context stack, as that may lead to a use-after-free.
This patch solves this by adding a `context_owner` field to each context
and treating it as a GC root.
This getter and setter were previously labelled as a "hack" and used to
disable style invalidation on attribute changes during the HTML parsing
phase (as it caused big sites's loading to be slow). These functions
are currently not used, so they can be removed:^)
This commit adds inline spec comments to the part of the parser that
ends up calling HTMLScriptElement::prepare().
The code is tweaked to match the spec more closely.
These lambdas were marked mutable as they captured a Ptr wrapper
class by value, which then only returned const-qualified references
to the value they point from the previous const pointer operators.
Nothing is actually mutating in the lambdas state here, and now
that the Ptr operators don't add extra const qualifiers these
can be removed.
Even if the pointer value is const, the value they point to is not
necessarily const, so these functions should not add the qualifier.
This also removes the redundant non-const implementations of these
operators.
Since ff2f31b LibWeb has segfaulted when clicking on links, as the
browsing context (a GCPtr) in the lambda was captured by reference
and was out of scope by the time the callback fired.
This implementation is some-what complete, with the most common missing
/broken feature being opening pages in new tabs using the "_blank"
target.
This is currently broken due to 2 reasons:
- We currently always claim the Window does not have transient
activation, as we do not track the transient activation timestamp
yet. This means that all such window.open calls are detected as
pop-ups, and as such they are blocked. This can be easily bypassed
by unchecking the 'Block Pop-ups' checkbox in the debug menu.
- There is currently no mechanism for the WebContent process to
request a new tab to be created by the Browser process, and as
such the call to BrowsingContext::choose_a_browsing_context does not
actually open another tab.
process_the_iframe_attributes already causes a navigation, so this
would cause a double navigation and blow away any setup that JS may
have done from events fired in process_the_iframe_attributes.
This was a missing spec step. This prevents it navigating to
about:blank, which will blow away the document and thus any setup that
was done in the iframe load event.
C++20 can automatically synthesize `operator!=` from `operator==`, so
there is no point in writing such functions by hand if all they do is
call through to `operator==`.
This fixes a compile error with compilers that implement P2468 (Clang
16 currently). This paper restores the C++17 behavior that if both
`T::operator==(U)` and `T::operator!=(U)` exist, `U == T` won't be
rewritten in reverse to call `T::operator==(U)`. Removing `!=` operators
makes the rewriting possible again.
See https://reviews.llvm.org/D134529#3853062
Once we know that the current code point is an ASCII character, we can
just check if it's one of the HTML whitespace characters.
Before this patch, we were using the generic StringView::contains(u32)
path that splats a code point into a StringBuilder and then searches
for it with memmem().
This reduces time spent in the HTML tokenizer from 16% to 6% when
loading the ECMA-262 spec.
When parsing relative URLs, we have to check the first <base href> in
tree order (if one is available). This was getting *very* costly on
large DOMs with many relative urls.
This patch avoids all that repeated traversal by letting Document cache
the first <base href> and invalidating the cache whenever a <base>
element is added/removed/edited in the DOM.
The browser was stuck doing this for a *very* long time when loading
the ECMA-262 spec, and this removes that problem entirely.
