In terms of the 'current principal realm' definition.
No functional impact, as we still need to implement current principal
realm once the surrounding infrastructure is in place. But it is one
less place which needs to be updated when that is all in place :^)
Aligning the name with the the PR implementing the javascript
shadow realm proposal into the web platform. This commit
simply performs the rename before implementing the behaviour
change.
The actual change to the behaviour of the AO is not implemented in this
commit to support 'synthetic' shadow realms as the surrounding
infrastructure is not in place yet.
Not all specs have a MR open to align with this proposed change to the
HTML standard. But in this case we can just apply the same mechanical
change everywhere.
This change also removes as much direct use of JS::Promise in LibWeb
as possible. When specs refer to `Promise<T>` they should be assumed
to be referring to the WebIDL Promise type, not the JS::Promise type.
The one exception is the HostPromiseRejectionTracker hook on the JS
VM. This facility and its associated sets and events are intended to
expose the exact opaque object handles that were rejected to author
code. This is not possible with the WebIDL Promise type, so we have
to use JS::Promise or JS::Object to hold onto the promises.
It also exposes which specs need some updates in the area of
promises. WebDriver stands out in this regard. WebAudio could use
some more cross-references to WebIDL as well to clarify things.
This aligns with an update to the HTML specification which instead
stores these promises on the global object instead of the settings
object.
It also makes progress towards implementing the ShadowRealm proposal
as these promises are not present in the 'synthetic' realm for that
proposal.
There was no need to use FlyString for error messages, and it just
caused a bunch of churn since these strings typically only existed
during the lifetime of the error.
While Origin is defined in the HTML spec - this leaves us with quite an
awkward relationship as the URL spec makes use of AO's from what is
defined in the HTML spec.
To simplify this factoring, relocate Origin into LibURL.
We now use the "report an exception" AO when a script has an execution
error. This has mostly replaced the older "report the exception" AO in
various specifications. Using this newer AO ensures that
`window.onerror` is invoked when a script has an execution error.
Looking at the spec it doesn't seem like there's a chance for a service
worker client to be an environment but not an environment settings
object. In the case that that changes in the implementation, we can
move it.
The EntryType has three possible values: Fetching, Failed or
ModuleScript. It is possible that we transition from Fetching to Failed
as in #13.1. Change the assertion to include the failed scenario.
Fixes: https://github.com/LadybirdBrowser/ladybird/issues/661
Fetch requests from web workers fail CORS checks because the origin is
not inherited from the outside settings. Ensure web worker origin is
correctly inherited from outside settings
The only subclass was already GC-allocated, so let's hoist the JS::Cell
inheritance up one level. This ends up simplifying a bit of rather
dubious looking code where we were previously slicing ESOs.
Changes the signature of queue_global_task() from AK:Function to
JS::HeapFunction to be more clear to the user of the function that this
is what it uses internally.
A bunch of this is leftover from pre porting over to new AK::String.
For example, for functions which previously took a ByteString const&
now accepting a StringView.
...and use HeapFunction instead of SafeFunction for task steps.
Since there is only one EventLoop per process, it lives as a global
handle in the VM custom data.
This makes it much easier to reason about lifetimes of tasks, task
steps, and random stuff captured by them.
Switching away from SafeFunction immediately backfired here, as we're
dealing with two layers of captures, not one.
Let's do the correct fix, which is to use HeapFunction. This makes the
API and its behavior explicit, and keeps captures alive as long as the
HeapFunction is alive.
Fixes#23819.
This URL library ends up being a relatively fundamental base library of
the system, as LibCore depends on LibURL.
This change has two main benefits:
* Moving AK back more towards being an agnostic library that can
be used between the kernel and userspace. URL has never really fit
that description - and is not used in the kernel.
* URL _should_ depend on LibUnicode, as it needs punnycode support.
However, it's not really possible to do this inside of AK as it can't
depend on any external library. This change brings us a little closer
to being able to do that, but unfortunately we aren't there quite
yet, as the code generators depend on LibCore.
