Hi API owners,

I just wanted to bump this. Does a new OT sound good to you?

Thanks,

Thomas

On Mon, Feb 23, 2026 at 9:09 AM Thomas Lively <[email protected]> wrote:

> Hi API owners,
>
> It turned out that we had to disable this origin trial in early October
> due to security issues reported to us by an external security researcher.
> As a result, the OT was only live for about three weeks. Since then, we've
> been hard at work fixing those bugs and improving our fuzzing for this
> feature.
>
> We are almost ready to try again, so I'd like permission to run a new OT
> for the same feature from M149 to M155.
>
> Please let me know if you have any questions.
>
> Thomas
>
> On Tue, Aug 19, 2025 at 7:37 AM Mike Taylor <[email protected]>
> wrote:
>
>> LGTM to experiment from M141 to M147 inclusive.
>> On 8/13/25 4:40 p.m., 'Thomas Lively' via blink-dev wrote:
>>
>> Good question! The first toolchain to support custom descriptors is j2cl
>> <https://github.com/google/j2cl>, which is an open source
>> Java-to-JS/Wasm compiler developed by Google. Developers will enable the
>> feature via an option
>> <https://github.com/google/j2cl/commit/a8cdfa7aa36d4c46e8b794139a38ccefcd99e5fb#diff-be4e99d1c21ff16eff4ab47ef7d35d297118d455e283f292745218a53d853553R147-R151>
>>  passed
>> to the compiler. We hope that once the feature is available via an origin
>> trial, other toolchains will be motivated to start experimenting with it as
>> well.
>>
>> Note that in the initial experiments we don't expect toolchains to expose
>> any new developer-facing functionality based on this feature. The use of
>> custom descriptors will only be an internal implementation detail in the
>> compiler that results in less memory usage at runtime. Later
>> experimentation will additionally enable the JS interop features built on
>> top of custom descriptors, and it will vary from toolchain to toolchain
>> whether this enables new developer-facing functionality or enables a
>> performance improvement in existing functionality.
>>
>> Also note that this feature will generally only be usable from
>> managed-memory languages that compile to WasmGC such as Java, Kotlin, and
>> Dart. It's unlikely that C/C++/Rust and similar languages will ever make
>> use of custom descriptors.
>>
>> On Wed, Aug 13, 2025 at 12:24 PM Daniel Bratell <[email protected]>
>> wrote:
>>
>>> I might have missed it, but how is this new feature going to be used by
>>> web developers? Do you have custom C compiler for the experiment? And do
>>> you need to do something in C to enable it? Or whatever language people
>>> prefer.
>>>
>>> /Daniel
>>> On 2025-08-13 20:04, Thomas Lively wrote:
>>>
>>> Yes, apologies. The explainer link should be the same as the
>>> specification link:
>>> https://github.com/WebAssembly/custom-descriptors/blob/main/proposals/custom-descriptors/Overview.md
>>>
>>> On Wed, Aug 13, 2025 at 7:58 AM Daniel Bratell <[email protected]>
>>> wrote:
>>>
>>>> The explainer link is dead, but maybe it was meant to be the same as
>>>> the Specification link?
>>>>
>>>> /Daniel
>>>> On 2025-08-12 00:50, 'Thomas Lively' via blink-dev wrote:
>>>>
>>>> Contact emails [email protected], [email protected],
>>>> [email protected]
>>>>
>>>> Explainer
>>>> https://github.com/WebAssembly/custom-descriptors/blob/main/proposals/custom-rtts/Overview.md
>>>> <https://github.com/WebAssembly/custom-rtts/blob/main/proposals/custom-rtts/Overview.md>
>>>>
>>>> Specification
>>>> https://github.com/WebAssembly/custom-descriptors/blob/main/proposals/custom-descriptors/Overview.md
>>>>
>>>> Summary
>>>>
>>>> Allows WebAssembly to store data associated with source-level types
>>>> more efficiently in new "custom descriptor" objects. These custom
>>>> descriptors can be configured with prototypes for the WebAssembly objects
>>>> of that source-level type. This allows methods to be installed on a
>>>> WebAssembly object's prototype chain and called directly from JS using
>>>> normal method call syntax. The prototypes and methods can be configured
>>>> declaratively using an imported builtin function.
>>>>
>>>>
>>>> Blink component Blink>JavaScript>WebAssembly
>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EJavaScript%3EWebAssembly%22>
>>>>
>>>> TAG review None
>>>>
>>>> TAG review status Pending
>>>>
>>>> Origin Trial documentation link
>>>> https://github.com/WebAssembly/custom-descriptors/blob/main/proposals/custom-descriptors/Overview.md
>>>>
>>>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> None
>>>>
>>>>
>>>> *Gecko*: No signal
>>>>
>>>> *WebKit*: No signal
>>>>
>>>> *Web developers*: No signals
>>>>
>>>> *Other signals*:
>>>>
>>>> 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?
>>>>
>>>> None
>>>>
>>>>
>>>> Goals for experimentation
>>>> Initially we are looking to measure real-world performance, heap usage,
>>>> and OOM rate impact of just the core Wasm part of the proposal. We want to
>>>> verify that heap usage and OOM rates will decrease as expected and that the
>>>> performance impact is negligible. If we do measure a performance impact,
>>>> that will inform additional optimization work we would need to do in the
>>>> implementation. Notably, the JS interop features of the proposal are out of
>>>> scope for this initial experimentation. They will likely be evaluated in
>>>> follow-on experiments.
>>>>
>>>>
>>>> Ongoing technical constraints
>>>>
>>>> None.
>>>>
>>>>
>>>> Debuggability
>>>>
>>>> None
>>>>
>>>>
>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? No
>>>>
>>>> Is this feature fully tested by web-platform-tests
>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>> ? No
>>>>
>>>> Flag name on about://flags None
>>>>
>>>> Finch feature name None
>>>>
>>>> Non-finch justification None
>>>>
>>>> Requires code in //chrome? False
>>>>
>>>> Estimated milestones
>>>> Origin trial desktop first 141
>>>> Origin trial desktop last 147
>>>>
>>>> Link to entry on the Chrome Platform Status
>>>> https://chromestatus.com/feature/6024844719947776?gate=5062088692858880
>>>>
>>>> This intent message was generated by Chrome Platform Status
>>>> <https://chromestatus.com/>.
>>>> --
>>>> 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 [email protected].
>>>> To view this discussion visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJZD_EWidxA-LogDRBnDVM9cOMbu3OX3_3onqCZcSLVJm7%3DnvA%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJZD_EWidxA-LogDRBnDVM9cOMbu3OX3_3onqCZcSLVJm7%3DnvA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> --
>> 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 [email protected].
>> To view this discussion visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJZD_EUC9rpqgjKR7QYC5jZ9OgdLJ4%2BVNW088%2BCbGOr9McnykQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJZD_EUC9rpqgjKR7QYC5jZ9OgdLJ4%2BVNW088%2BCbGOr9McnykQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJZD_EXPxAdP0A%3DHuvpYnozYRjw9rmXMTHiBV-5nh3k8EameeQ%40mail.gmail.com.

Reply via email to