Intent to Extend Experiment: JavaScript Promise Integration
Chromestatus
Contact emails
f...@chromium.orgExplainer
https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.mdSpecification
https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.mdDesign 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>WebAssemblySearch tags
stack switching, Promise, JSPITAG review
https://github.com/w3ctag/design-reviews/issues/809 Review was declined, deferring to W3C WebAssembly CGTAG review status
PendingChromium Trial Name
WebAssemblyJSPromiseIntegrationOrigin Trial documentation link
https://github.com/WebAssembly/js-promise-integrationWebFeature UseCounter name
kV8WasmJavaScriptPromiseIntegrationRisks
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 started their own imlementation
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 was a change in the API which we soft launched in M126 but we would like to formally switch to this new API in M129. (We had informed our users that we would be maintaining the old API through the end of the OT.) So, in summary there are two reasons for extending the origin trial: 1. We are not quite ready to move the spec to phase 4. This is for non-implementation reasons: we need to draft and review the specification text; which, for a feature like JSPI is not completely trivial. 2. We would like to allow sufficient time for users to fully experiment with the new API. We anticipate being able to fully ship JSPI before the end of 2024.
Reason this experiment is being extended
We wish to extend the OT for JSPI for a second time. Hopefully, this will be the last extension before shipping. We have recently implemented one of the key technology improvements that we believed necessary for shipping: growable stacks. However, performance remains a blocker for some partners and we would like to be able to continue performance improvements. The specification itself should be moving to phase 4 in the standards process; hopefully in the next few months.
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)?
YesIs this feature fully tested by web-platform-tests?
NoFlag name on chrome://flags
enable-experimental-webassembly-stack-switchingFinch feature name
NoneNon-finch justification
NoneRequires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/v8/issues/detail?id=12191&q=owner%3Ame&can=2Estimated 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 |
| 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=5414230854205440Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAdKk6BGFseZ6pBO2qEW_xeovVw1_guVq26rcNM1nWY442Y5Ng%40mail.gmail.comIntent 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
Alex Russell
- Is the OT documentation link correct?
- Have we requested a position from WebKit? Seems like we're far enough along to start on that.
- If I understand this correctly, there was a *breaking* change in 129? If so, that's helpful for requesting an end-to-end this long, as it would reset the "burn in" clock.
- Has there been feedback from the original OT that you can share?
- Why shouldn't we just ship this now? I understand the WASM WG process arguments, but if we've got good confidence in the current API shape and the developer feedback on the M129+ API shape is positive, we might look to send I2S before this OT ends (with a gapless OT). How are y'all thinking about that?
