FIXME addressed in open method:
10. If async is false, the current global object is a Window object,
and either this’s timeout is not 0 or this’s response type is not the
empty string, then throw an "InvalidAccessError" DOMException.
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().
The XHR gives us a set of conditions where XHR objects must survive
garbage collection, even when there are no pointers to them on the heap.
This patch implements those conditions using the new cell
self-protection mechanism in LibJS.
This allows us to use this:
```cpp
auto header = TRY_OR_RETURN_OOM(realm,
Infrastructure::Header::from_string_pair(name, value));
```
Instead of the somewhat unwieldly:
```cpp
auto header = Infrastructure::Header {
.name = TRY_OR_RETURN_OOM(realm, ByteBuffer::copy(name.bytes())),
.value = TRY_OR_RETURN_OOM(realm, ByteBuffer::copy(value.bytes())),
};
```
This changes the signature of LoadRequest::set_body() to take by value
and then use move semantics to move the contents of the ByteBuffer.
This is done to avoid the fallible copy constructor of ByteBuffer.
URL had properly named replacements for protocol(), set_protocol() and
create_with_file_protocol() already. This patch removes these function
and updates all call sites to use the functions named according to the
specification.
See https://url.spec.whatwg.org/#concept-url-scheme
Let's stop putting generic types and AOs from the Web IDL spec into
the Bindings namespace and directory in LibWeb, and instead follow our
usual naming rules of 'directory = namespace = spec name'. The IDL
namespace is already used by LibIDL, so Web::WebIDL seems like a good
choice.
Unlike ensure_web_prototype<T>(), the cached version doesn't require the
prototype type to be fully formed, so we can use it without including
the FooPrototype.h header. It's also a bit less verbose. :^)
This is a monster patch that turns all EventTargets into GC-allocated
PlatformObjects. Their C++ wrapper classes are removed, and the LibJS
garbage collector is now responsible for their lifetimes.
There's a fair amount of hacks and band-aids in this patch, and we'll
have a lot of cleanup to do after this.
This patch moves the following things to being GC-allocated:
- Bindings::CallbackType
- HTML::EventHandler
- DOM::IDLEventListener
- DOM::DOMEventListener
- DOM::NodeFilter
Note that we only use PlatformObject for things that might be exposed
to web content. Anything that is only used internally inherits directly
from JS::Cell instead, making them a bit more lightweight.
Intrinsics, i.e. mostly constructor and prototype objects, but also
things like empty and new object shape now live on a new heap-allocated
JS::Intrinsics object, thus completing the long journey of taking all
the magic away from the global object.
This represents the Realm's [[Intrinsics]] slot in the spec and matches
its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of
architecture.
In the majority of cases it should now be possibly to fully allocate a
regular object without the global object existing, and in fact that's
what we do now - the realm is allocated before the global object, and
the intrinsics between both :^)
- Prefer VM::current_realm() over GlobalObject::associated_realm()
- Prefer VM::heap() over GlobalObject::heap()
- Prefer Cell::vm() over Cell::global_object()
- Prefer Wrapper::vm() over Wrapper::global_object()
- Inline Realm::global_object() calls used to access intrinsics as they
will later perform a direct lookup without going through the global
object
Similar to create() in LibJS, wrap() et al. are on a low enough level to
warrant passing a Realm directly instead of relying on the current realm
from the VM, as a wrapper may need to be allocated while no JS is being
executed.
This is a continuation of the previous two commits.
As allocating a JS cell already primarily involves a realm instead of a
global object, and we'll need to pass one to the allocate() function
itself eventually (it's bridged via the global object right now), the
create() functions need to receive a realm as well.
The plan is for this to be the highest-level function that actually
receives a realm and passes it around, AOs on an even higher level will
use the "current realm" concept via VM::current_realm() as that's what
the spec assumes; passing around realms (or global objects, for that
matter) on higher AO levels is pointless and unlike for allocating
individual objects, which may happen outside of regular JS execution, we
don't need control over the specific realm that is being used there.
Blob::bytes() returns the ReadonlyBytes representation of our internal
ByteBuffer.
This change requires us to ByteBuffer::copy() Blob's ReadonlyBytes to a
ByteBuffer in XHR::send() and corresponding error handling of the copy
operation.
This removes the need for Blob to declare XMLHttpRequest as a friend
class.
This is a minor refactor of XHR::extract_body() letting it return
ErrorOr<...> instead of just Fetch::Infrastructure::BodyWithType.
This also updates the one place extract_body() is used.
The Fetch spec unfortunately will cause a name clash between the Request
concept and the Request JS object - both cannot live in the Web::Fetch
namespace, and WrapperGenerator generally assumes `Web::<Name>` for
things living in the `<Name>/` subdirectory, so let's instead move infra
code into its own namespace - it already sits in a (sub-)subdirectory
anyway.
