WebAssembly.{Module, Memory, Instance, ...} should be subclassable
Categories
(Core :: JavaScript: WebAssembly, defect, P3)
Tracking
()
| 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).
|
Reporter | |
Comment 1•4 years ago
|
||
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.).
|
||
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 3•4 years ago
|
||
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.
|
||
Updated•4 years ago
|
|
||
Comment 4•4 years ago
|
||
Resetting severity to default of --.
|
|
||
Comment 5•4 years ago
|
||
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
|
||
Comment 7•4 years ago
•
|
||
Backed out changeset af13eadc6370 for causing sm failures in js/src/gc/Cell.h
Backout link: https://hg.mozilla.org/integration/autoland/rev/fe5f608d8c54a4ee287e5be9c0c3eb761be3e5e7
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=299581325&repo=autoland&lineNumber=8763
Update:
xpcshell failures: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=299585659&repo=autoland&lineNumber=8550
|
|
Assignee | |
Comment 8•4 years ago
|
||
Depends on D70965
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 9•4 years ago
|
||
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.
|
||
Comment 10•4 years ago
|
||
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
|
||
Comment 11•4 years ago
|
||
| bugherder | ||
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
Description
•