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.
With so much infrastructure implemented, we can finally add the last
piece of this puzzle - the fetch() method itself!
This contains a few hundred lines of generated code as handling the
RequestInfo and RequestInfo parameter types manually is not feasible,
but we can't use the IDL definition as the Window object is handwritten
code at the moment.
It's neatly tucked away in Bindings/ and will be removed eventually.
This is the way.
On a more serious note, there's no reason to keep adding ref-counted
classes to LibWeb now that the majority of classes is GC'd - it only
adds the risk of discovering some cycle down the line, and forces us to
use handles as we can't visit().
This patch implements all changes to the specification touching the
subset of module script fetching we support.
Notably it adds parts of the specification for supporting import maps.
With this we are also able to get rid of a non standard workaround for a
spec issue we discovered while initially implementing module scripts :^)
