Bug 267323 – REGRESSION(270429@main): [Win Wasm] Nothing is shown in https://threejs.org/examples/#webgl_animation_keyframes

• Component: WebAssembly
• Status: RESOLVED FIXED

[Fujii Hironori]

[Win] Nothing is shown in https://threejs.org/examples/#webgl_animation_keyframe

1. Start WinCairo Release MiniBrowser
2. Load https://threejs.org/examples/#webgl_animation_keyframe
3. Select the first demo
4. No object is shown

I did bisecting with my WinCairo collection.

270065@main good
270682@main bad

[Fujii Hironori]

270429@main is the regression point.

[Ian Grunert]

Looks like if webassembly is available it uses a wasm decoder for 3D meshes

https://github.com/mrdoob/three.js/tree/534737d242a82239d7e89457ba6005810a361153/examples/jsm/libs/draco

So something in Windows LLInt breaks on that wasm.

[Radar WebKit Bug Importer]

<rdar://problem/121103304>

[Fujii Hironori]

This problem can be worked around by disabling WASM. 
$env:JSC_useWebAssembly = 0

[Ian Grunert]

This is still an issue on main after the changes to switch to SystemV ABI JSC on Windows. Doesn't repro on Epiphany running under WSL either, so seems Windows-specific rather than something in x86_64.

[Ian Grunert]

Created attachment 472191 [details]
instantiate in worker fails

Here's a minimal repro - WebAssembly.instantiate doesn't work within a Web Worker on Windows.

[Ian Grunert]

The callback scheduled in JSWebAssembly.cpp compileAndInstantiate via vm.deferredWorkTimer->scheduleWorkSoon is never called:

https://github.com/WebKit/WebKit/blob/main/Source/JavaScriptCore/wasm/js/JSWebAssembly.cpp#L255-L275

After vm.deferredWorkTimer->scheduleWorkSoon is called, DeferredWorkTimer::doWork is never called. This is also a problem for compileStreaming which uses the deferredWorkTimer as well.

The docs for SetTimer state the HWND passed must be owned by the calling thread; we're trying to use the parent's runloop here from the web worker thread.

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-settimer

A possible fix: We could store the thread id that owns the runloop. If you try and set a timer from a different thread, we could PostMessageW to the window a ScheduleTimerMessage (that we define like we do for PerformWorkMessage) which could then call SetTimer from the correct thread.

[Ian Grunert]

Pull request: https://github.com/WebKit/WebKit/pull/32602

[EWS]

Committed 282906@main (f659dfd72562): <https://commits.webkit.org/282906@main>

Reviewed commits have been landed. Closing PR #32602 and removing active labels.