Specify realm for object creation

[domenic]

As pointed out by @mgaudet in Matrix, the spec is not clear on what realms things should be created in, and the result is not interoperable across browsers.

To audit:

• All references to Web IDL "new"
• All references to "a new promise" / "a promise rejected with" / "a promise resolved with"
• All raw ES-spec object creation using %% intrinsics, although some of these might be able to be replaced with the stuff introduced in Add and improve operations on BufferSources webidl#987

Per whatwg/webidl#135 the intention is to use the relevant realm of this. Alternately we could fix that issue at its source per whatwg/webidl#135 (comment) ... that's quite tempting.

[ricea]

Currently Blink's implementation is quite confused here, so it would be nice to have it clarified.

[minfrin]

Spent a while hitting my head on this, and not found a way around it yet:

https://bugzilla.mozilla.org/show_bug.cgi?id=1757066

The two errors encountered are:

TypeError: controller.enqueue is not a function
Error: Permission denied to access property "then"

Streams can't work with web extensions on Firefox, which is a real pity - as streams are needed to handle the arbitrary size limits in the web extensions API.

[ricea]

TypeError: controller.enqueue is not a function Error: Permission denied to access property "then"

Streams can't work with web extensions on Firefox, which is a real pity - as streams are needed to handle the arbitrary size limits in the web extensions API.

This seems to be an issue with web extensions on Firefox rather than anything we can fix in the streams standard.

[saschanaz]

The new test in web-platform-tests/wpt#38875 implicitly requires TransformStream to be created with the caller realm, which doesn't match with Gecko's this behavior. Perhaps we should finally get some normative spec here.

That said, what should happen when creating a promise with a detached realm?

[ricea]

The intent of the test is that it be created in the realm of the constructor. Probably we should add some comments.

Edit: Incidentally, the point of the test is that Chromium fails it, so we haven't actually tested the success case. The Chromium-only test https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/streams/transform-streams/invalid-realm.window.js documents our actual behaviour.

[saschanaz]

But wpt.fyi says it passes on Chrome? (Adding a failing test sounds weird, such test should at least be marked as tentative.)

[ricea]

But wpt.fyi says it passes on Chrome? (Adding a failing test sounds weird, such test should at least be marked as tentative.)

The test previously worked in Chrome, but updating our implementation to use read requests broke it (we switched from using promises to enqueuing microtasks directly, and it turns out that has different semantics in V8). Currently the Chrome dev channel is still on version 113, which is why it shows as passing on wpt.fyi. It will show as failing once the dev channel moves on to version 114.

As the test relies on behaviour that is not yet specced, I think you are right that it should be tentative. However, in general I think when we find a test gap it's good to write a test for it, even if for some reason we can't pass that test.

[saschanaz]

As the test relies on behaviour that is not yet specced, I think you are right that it should be tentative. However, in general I think when we find a test gap it's good to write a test for it, even if for some reason we can't pass that test.

+1. For now I'd like to mark it as tentative to prevent confusion from our side.