[css-houdini-drafts] [worklets-1] Worklet specs are generally impossible to integrate with WebAssembly without going through JS (#945)

bzbarsky has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== [worklets-1] Worklet specs are generally impossible to integrate with WebAssembly without going through JS ==
People are talking about adding IDL bindings for Web Assembly.  Once that happens, specs that leverage IDL will start Just Working with Web Assembly without having to go through JS.  But the Worklet specs typically assume that the objects they are handed are in fact JS objects, and directly manipulate them as JS objects.

For example, https://drafts.css-houdini.org/css-paint-api-1/#dom-paintworkletglobalscope-registerpaint step 5 assumes that the VoidFunction it was handed is an actual JS function and performs https://tc39.es/ecma262/#sec-get-o-p on it directly.  Similar for step 9, step 13, steps 15-18.

Or for a different worklet spec, https://webaudio.github.io/web-audio-api/#dom-audioworkletglobalscope-registerprocessor makes that assumption in steps 3-7.

Or for a different one, https://drafts.css-houdini.org/css-animationworklet/#dom-animationworkletglobalscope-registeranimator steps 3-5 and step 7, same thing.

In all these cases, what is really desired is to pass in a "constructor" and then do the following:

1) Verify that it is in fact a constructor.  Right now IDL has no way to express that, but see <https://github.com/heycam/webidl/issues/701>.
2) Grab some data values from the constructor.
3) Grab `.prototype` from the constructor and validate that it's an object.
4) Grab some data values from the prototype.

I believe all of 2-4 are doable by defining appropriate IDL dictionaries.  Unfortunately, that does not give a simple way to do item 1.

Per https://github.com/heycam/webidl/issues/701#issuecomment-478624111 maybe we should add explicit IDL syntax for "a thing that is like a JS class" which would allow defining the args the constructor takes, and which things one can get off the constructor and off the prototype.  This could then get mapped to WebAssembly in some sane way.  @lukewagner

In the meantime, it might be worth it to recast the various algorithms involved in a way that minimizes the ES dependency by taking the constructor (as a callback function for now), converting the corresponding ES object to a dictionary up front (to get all the bits from the constructor and prototype and whatnot in the form of IDL values), and then working with IDL values, not JS values.  That should help flush out any other ES-specific bits hiding in these specs.

Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/945 using your GitHub account

Received on Friday, 13 September 2019 00:55:32 UTC