Currently, for each exposed interface, we generate one massive function
to create every Web constructor and prototype. In an effort to lazily
create these instead, this first step is to extract the creation of each
of these into its own method.
First, this generates a forwarding header for all IDL types. This is to
allow callers to remain unchanged without forcing them to include the
(very heavy) generated IDL headers. This header is included by LibWeb's
forwarding header.
Next, this defines a base template method on Web::Bindings::Intrinsics
to create a prototype/constructor pair. Specializations of this template
are now generated in a new .cpp file, IntrinsicDefinitions.cpp. The base
Intrinsics class is updated to use this new method, and will continue to
cache the result.
Last, some WebAssembly classes are updated to use this new mechanism.
They were using some ad hoc cache keys that are now in line with the
generated specializations.
That one massive function is still used to invoke these specializations,
so they are not lazy as of this commit.
This makes construction of Utf16String fallible in OOM conditions. The
immediate impact is that PrimitiveString must then be fallible as well,
as it may either transcode UTF-8 to UTF-16, or create a UTF-16 string
from ropes.
There are a couple of places where it is very non-trivial to propagate
the error further. A FIXME has been added to those locations.
Move the macro to LibJS and change it to return a throw completion
instead of a WebIDL exception. This will let us use this macro within
LibJS to handle OOM conditions.
Note that js_rope_string() has been folded into this, the old name was
misleading - it would not always create a rope string, only if both
sides are not empty strings. Use a three-argument create() overload
instead.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
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.
This ensures that the controller GCPtr is non-null by the time we
capture a copy of it for the lambda passed to the request signal's
add_abort_algorithm() method. Currently, the VERIFY() would always fail
when aborting the signal. The alternative to this would be adding a cell
setter to Handle, and ensuring that null handles have a HandleImpl as
well; this seems not worth the hassle right now. Thanks to Lubrsi for
catching this!
Co-authored-by: Luke Wilde <lukew@serenityos.org>
We were accidentally copying these from the newly created Request
object's underlying request, to itself. Thanks to Lubrsi for catching
this!
Co-authored-by: Luke Wilde <lukew@serenityos.org>
This was an oversight from when I converted PendingResponse and various
other classes from being ref-counted to GC-allocated last minute - no
one takes care to keep all of them alive. Some are on the stack, and
some might be captured in another PendingResponse's JS::SafeFunction,
but ultimately, we need a better solution.
Since a PendingResponse is *always* the result of someone having created
a Request, let's just let that keep a list of each PendingResponse that
has been created for it, and visit them until they are resolved. After
that, they can be GC'd with no complaints.
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 implements the following operations from section 4 of the Fetch
spec (https://fetch.spec.whatwg.org/#fetching):
- Fetch
- Main fetch
- Fetch response handover
- Scheme fetch
- HTTP fetch
- HTTP-redirect fetch
- HTTP-network-or-cache fetch (without caching)
It does *not* implement:
- HTTP-network fetch
- CORS-preflight fetch
Instead, we let ResourceLoader handle the actual networking for now,
which isn't ideal, but certainly enough to get enough functionality up
and running for most websites to not complain.
There will be a lot of different cases where we'll return an error
response, and having a customized Promise rejection message seems quite
useful.
Note that this has to be distinct from the existing 'status message',
which is required to be empty in those cases.
The header-specific ABNF rules are completely ignored for now, but we
can at least extract a single header value, which at least works for
simple cases like `Location`-based redirects.
