Intent to Extend Experiment: JavaScript Promise Integration

[Francis McCabe]

Contact emails

f...@chromium.org

Explainer

https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md

Specification

https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md

Design docs

https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#heading=h.n1atlriavj6v

Summary

Stack Switching denotes a technology that allows programs to suspend and resume computation. This is an active area that is part of the WebAssembly standards track. See https://github.com/WebAssembly/stack-switching and https://github.com/WebAssembly/meetings/tree/main/stack. This particular feature refers to the integration between JavaScript Promises and stack switching. This is described in more detail in https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#

Blink component

Blink>JavaScript>WebAssembly

Search tags

stack switching, Promise, JSPI

TAG review

https://github.com/w3ctag/design-reviews/issues/809 Review was declined, deferring to W3C WebAssembly CG

TAG review status

Pending

Origin Trial Name

WebAssembly JavaScript Promise Integration

Chromium Trial Name

WebAssemblyJSPromiseIntegration

Origin Trial documentation link

https://github.com/WebAssembly/js-promise-integration

WebFeature UseCounter name

kV8WasmJavaScriptPromiseIntegration

Risks

Interoperability and Compatibility

This spec is backed by a standardization effort. We do not plan to ship the JSPI until it has been standardized by the W3C Wasm WG. However, post standardization, we will depend on all browsers implementing the standard.

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1850627) Mozilla have an experimental imlementation available in the nightly build

WebKit: No signal

Web developers: No signals

Other signals:

Activation

Making use of JSPI requires some changes by WebAssembly-based developers (no impact on JavaScript developers). Depending on their toolchain usage a developer will need to modify their code. For Emscripten users, this is likely to be minimal as support for JSPI exists in Emscripten.

Security

1. Control flow integrity. 2. Ensuring that JavaScript programs cannot suspend via JSPI.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Goals for experimentation

Reason this experiment is being extended

JSPI is part of a standards track effort. We are currently in 'stage 3' of a five stage process. The next stage (4) is when a specification is deemed final.

There have been one or two small changes to the API which have prevented moving to phase 4. The text of the specification is much closer to being final than in previous rounds of the origin trial. However, we would like some time to further bake the revised API.

We anticipate being able to fully ship JSPI before the end of 2025Q2.

Ongoing technical constraints

None.

Debuggability

Developers can piggyback on existing DevTools support for Promises to help with debugging JSPI applications. In particular the existing mechanisms for constructing extended stack traces from so-called Promise chains will also include stack traces from JSPI applications.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name on about://flags

enable-experimental-webassembly-jspi

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=12191&q=owner%3Ame&can=2

Estimated milestones

Origin trial desktop first	123
Origin trial desktop last	131
Origin trial extension 1 end milestone	131
Origin trial extension 2 end milestone	133
Origin trial extension 3 end milestone	136
DevTrial on desktop	109
Origin trial Android first	123
Origin trial Android last	131
Origin trial WebView first	123
Origin trial WebView last	131

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5674874568704000?gate=5136083140214784

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAdKk6BGFseZ6pBO2qEW_xeovVw1_guVq26rcNM1nWY442Y5Ng%40mail.gmail.com
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/Fu79zrp7MoE
Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALi9WK-JJNTYSeNdSuai827Qg5%3D2vZo-emYP2z-5vJOfE%2B8Nng%40mail.gmail.com
Intent to Extend Experiment 2: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67103777.2b0a0220.137ef7.0e4c.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Hey Francis,

This feature is exciting, and I'm glad to see it moving forward. That said, this extension would push the OT past a year, which is a bit of a concern. Have you considered, perhaps, pushing forward with a gapless intent-to-ship? If you're happy with the developer feedback to date, and intend to ship this API shape, I'd be more willing to approve the OT extension if it was in the shadow of getting this into the hands of developers. The counterpoint might be that we expect to learn something important and new in this extension that we haven't learned in the previous OT windows, which would be somewhat surprising, but can happen. Is that likely?

Best,

Alex

[Francis McCabe]

I also did not wish to have to extend the OT :)

We encountered a couple of issues:

1. We had some late breaking requests to modify the API; this is a standards-track effort. I think that this sometimes happens when we are about to finalize a spec!

2. We have had a few reports of exploitable bugs. Due to the holidays etc, it has taken us some time to fix them. And we would really like to do our best to let the dust settle a bit more before shipping.

We plan to go for phase 4 in early February. Assuming that that succeeds, we will be in a position to ship soon after.

Francis

[Deepti Gandluri]

Adding to Francis's reply, JSPI has been inherently hard to specify, and validate security requirements for given that it is somewhat sandwiched between JS & Wasm. Concretely, since the last OT extension, the late breaking changes have been merged into the specification and we've gotten more signals about the exploitable security surface of JSPI (OT features are treated as shipped features for V8), and we'd like to focus on hardening security ahead of an intent to ship. 

At each extension milestone, we've had high quality feedback for performance, API usage and the security surface exposed. I'd also like to add that trials for Wasm features do inherently take longer than regular Web APIs because it is at the lowest levels of Web APIs. Once a feature is available, it does take some time for the feature usage to be implemented by the libraries or frameworks, and enabled in the end applications which need updated versions of libraries frameworks. Ideally, we would like all of these to happen in lock step, but realistically that doesn't always happen. 

-Deepti

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/29cdb43b-2512-4595-806d-c90cbc9d0ce6n%40chromium.org.

[Chris Harrelson]

LGTM

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANT_J8ewyDV5E%2Bkfnwa5ZrJLGLAVD8FWA68%2BBxMttOh_%2BYg6jA%40mail.gmail.com.