Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LibWeb: Shadow Realm integration - part 2 #1932

Merged
merged 10 commits into from
Nov 1, 2024

Conversation

shannonbooth
Copy link
Contributor

@shannonbooth shannonbooth commented Oct 23, 2024

Second stage of shadow realm integration into LibWeb sitting ontop of #1927

The step after this is to change HTML::Script to operate on realm's instead of environment setting objects. After that, we should then be able to hook up the VM hook to actually initialize the shadow realm global object - which is enough for the test case of:

<script>
async function test() {
    const realm = new ShadowRealm()
    const aSync = realm.evaluate(`async () => 1 + 1`)
    aSync()
}

test();
</script>

To not crash :^)

Edit: For a mostly-working implementation, see: #1993

@ADKaster
Copy link
Member

Pre-review comment: I remember Luke Warlow mentioning in discord that the example there is supposed to throw, do we handle that yet? or is that later :)

@shannonbooth
Copy link
Contributor Author

shannonbooth commented Oct 23, 2024

Pre-review comment: I remember Luke Warlow mentioning in discord that the example there is supposed to throw, do we handle that yet? or is that later :)

I have that specific test case working (throwing an exception as expected) - but it needs another set of changes ontop of this.

Primarily:

  • Changing HTML::Script to hold a Realm instead of Settings Object
  • Implementing the concept of a 'synthetic realm' which is stored in [[HostDefined]] for a shadow realm (a primary realm is effectively meant to represent the same thing as what LibWeb uses today)
  • Hooking up the host defined callback from LibJS to LibWeb in MainVMThread.cpp
  • Defining the shadow realm global object

Which is enough for that test case to work, but we crash when running the WPT tests for Shadow Realms are there are still some items to check off to implement after that

@shannonbooth
Copy link
Contributor Author

Pushed rebase to fix de conflict

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.
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 :^)
Again, following a rename as part of the introduction of shadow realms
inducing a bunch of mechanical changes.
No functional change, as it is using the yet to be fully implemented
'current_principal_realm'.
To align with spec updates. No functional changes.
Instead of a settings object. This matches updates to the HTML spec as
part of the shadow realm proposal, and begins the refactor of running
scripts on a realm instead of a settings environment object.

Some of the spec steps are slightly messy here (such as in
MainThreadVM.cpp) as this partially implements the ShadowRealm changes
but not other pieces which we have not implemented yet, such as
preparing to run a script also being based on a realm instead of an
environment. But this will be addressed in further commits.
Alongside some const qualfied getters that this requires.
Taking further steps towards implementing the shadow realm spec :^)
Making further progress porting away from depending on the
EnvironmentSettingObject.
This is a bit of a chonkier commit as it results in both:

clean_up_after_running_callback and prepare_to_run_callback being
changed to accept a realm instead of an environment settings object,
which has a bunch of fallout, particuarly for IDL abstract operations.
Copy link
Member

@ADKaster ADKaster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part seems pretty reasonable to me. Two comments about how we're going to follow-up or track changes to other specs, but they don't need to be addressed before getting this set in main, I don't think.

I think after this shadow realm work is in, we can revisit the libgc changes. We'll want that for wasm gc at the very least. And would be best to not be juggling too many sweeping changes at once.

@@ -41,7 +41,7 @@ JS::ThrowCompletionOr<JS::NonnullGCPtr<JS::Object>> AudioConstructor::construct(
auto& vm = this->vm();

// 1. Let document be the current global object's associated Document.
auto& window = verify_cast<HTML::Window>(HTML::current_global_object());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the first commit you updated the copied spec text language to add "principal" for the ESO. Seems a miss here, and in Animations/Animation.cpp.

... and more. Perhaps best to leave that to a tracking issue in html/shadow realms

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, that is a miss on my end for this one. It is covered in the open merge request, see: https://whatpr.org/html/9893/b8ea975...32ad7a4/media.html#dom-audio

I did a scan over the spec folders for specs which have an open MR, but missed this one since it's in the Bindings folder. Will do a second scan over and adjust

@ADKaster ADKaster merged commit d7023f5 into LadybirdBrowser:master Nov 1, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants