We should not GC allocate in the constructors of GC-allocated objects
because a new allocation might trigger garbage collection, which in
turn might access not fully initialized objects.
In FetchAlgorithms, it is common for callbacks to capture realms. This
can indirectly keep objects alive that hold FetchController with these
callbacks. This creates a cyclic dependency. However, when
JS::HeapFunction is used, this is not a problem, as captured by
callbacks values do not create new roots.
Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
This adds a simple and incomplete implementation for extracting some
specific CORS headers that are used by fetch. This unifies the existing
ad-hoc parsing that already existed for Access-Control-Allow-Headers
and Access-Control-Allow-Methods, as well as adding
Access-control-Expose-Headers.
This adds the headers named in Access-Control-Expose-Headers to the
response's CORS-exposed header-name list which allows those headers to
be accessed from JS.
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.
The HTMLMediaElement will need to stop fetching processes when its load
algorithm is invoked while a fetch is ongoing. We don't have a way to
really stop the process, due to the way it runs on nested deferred task
invocations. So for now, this swaps the fetch callbacks (e.g. to process
a fetch response) with empty callbacks.
This makes Fetch rely less on using main_thread_vm().current_realm(),
which relies on the dummy execution context if no JavaScript is
currently running.
The majority of error strings are StringView literals, and it seems
silly to require heap-allocating strings for these.
This idea is stolen from a recent change in fd1fbad :^)
This includes an Error::create overload to create an Error from a UTF-8
StringView. If creating a String from that view fails, the factory will
return an OOM InternalError instead. VM::throw_completion can also make
use of this overload via its perfect forwarding.
We can't keep a span (ReadonlyBytes) to a move()'d ByteBuffer
in the header_names_seen HashTable - copy the original name span instead
which works the same thanks to CaseInsensitiveBytesTraits.
This would sporadically fail the contains() check due to garbage data,
later leading to a VERIFY() crash in the OrderedHashTable append loop.
Previously, parsing failures and the header not existing made
extract_header_list_values return an empty Optional, making it
impossible to differentiate between the two.
Required for implementing CORS-preflight, where parsing failures for
the headers makes it fail, but not having them doesn't make it fail in
all cases.
Having an alias function that only wraps another one is silly, and
keeping the more obvious name should flush out more uses of deprecated
strings.
No behavior change.
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.