I can't find of a way to trigger this codepath, and there is for sure no
correpsonding WPT test, but let's fix this up for whenever it does
become relevant.
The spec intends to pass through a URL record object as it needs to
be serialized on removal. This has no functional impact on our
implementation other than the double parsing of every URL being
revoked.
It is also missing an error check for an invalid URL being passed
through. This does not impact our implementation currently as we
just end up using an empty URL which is not part of the blob entry
map. This will cause problems once DOMURL::parse is updated to
return an Optional<URL::URL> however.
Which will have proper handling of the exection context when performing
a microtask checkpoint. This fixes an assertion to be added in the next
commit where perform_a_microtask_check is invoked on a non-empty
execution context stack.
C++ will jovially select the implicit conversion operator, even if it's
complete bogus, such as for unknown-size types or non-destructible
types. Therefore, all such conversions (which incur a copy) must
(unfortunately) be explicit so that non-copyable types continue to work.
NOTE: We make an exception for trivially copyable types, since they
are, well, trivially copyable.
Co-authored-by: kleines Filmröllchen <filmroellchen@serenityos.org>
This is necessary to avoid a circular reference when including
Serializable.h in DOMException.h.
This moves the definition of SerializationRecord, SerializationMemory,
and DeserializationMemory into LibWeb/Forward.h so that Serializable.h
only needs to include LibWeb/Forward.h.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.
