Closed Bug 1629998 Opened 9 months ago Closed 9 months ago

WebAssembly.{Module, Memory, Instance, ...} should be subclassable

Categories

(Core :: Javascript: WebAssembly, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox78 --- fixed

People

(Reporter: me, Assigned: rhunt)

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36

Steps to reproduce:

Paste this in DevTools (feel free to replace bytes with any other valid Wasm bytecode):

class M extends WebAssembly.Module {};
m = new M(new Uint8Array([0,97,115,109,1,0,0,0,1,133,128,128,128,0,1,96,0,1,127,3,130,128,128,128,0,1,0,4,132,128,128,128,0,1,112,0,0,5,131,128,128,128,0,1,0,1,6,129,128,128,128,0,0,7,145,128,128,128,0,2,6,109,101,109,111,114,121,2,0,4,109,97,105,110,0,0,10,138,128,128,128,0,1,132,128,128,128,0,0,65,42,11]));
m instanceof M

Actual results:

Expression evalutes to false (m is an instance of parent class WebAssembly.Module).

Expected results:

Expression evaluates to true (m is an instance of a subclass M).

See https://github.com/WebAssembly/spec/issues/1107 for upstream discussion in the spec (TL;DR - this should be already valid and works in JSC, but seems to be implemented incorrectly in V8 and SpiderMonkey).

Also note that while I used WebAssembly.Module in the example, same applies and should be fixed for all classes within the WebAssembly namespace (Instance, Memory, Global, etc.).

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Javascript: WebAssembly
Product: Firefox → Core
Assignee: nobody → rhunt

Wasm JS-API objects should be subclassable, and the following should work:

class M extends WebAssembly.Module {};
m = new M(...)
m instanceof M // true

The current code will always set the prototype to the original Wasm prototype,
and not the derived prototype.

This commit was written by following the example of
ArrayBufferObject::class_constructor which handles this situation.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Version: 76 Branch → Trunk

Resetting severity to default of --.

Would be useful to upstream the test case, as upstream tests don't test for this (or we would have found the problem).

Pushed by rhunt@eqrion.net:
https://hg.mozilla.org/integration/autoland/rev/af13eadc6370
Use correct prototype for Wasm JS-API objects when subclassed. r=jwalden

Depends on D70965

Attachment #9140644 - Attachment description: Bug 1629998 - Use correct prototype for Wasm JS-API objects when subclassed. r?lth → Bug 1629998 - Use correct prototype for Wasm JS-API objects when subclassed. r?jwalden
Attachment #9145348 - Attachment is obsolete: true

Turns out that asm.js requires the ability to create WasmJS objects with null proto's so that it can be parsed off-main-thread. I had to do some more digging to understand the prototype/object creation code and I've slightly updated the patch to work correctly for all cases now. Also added a WPT.

Flags: needinfo?(rhunt)
Pushed by rhunt@eqrion.net:
https://hg.mozilla.org/integration/autoland/rev/35777c0da53b
Use correct prototype for Wasm JS-API objects when subclassed. r=jwalden
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/23402 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.