The previous thread was locked because a user was abusively bumping the topic with needless comments.

However, it's a thread that myself and a few others in my community have been silently monitoring for months, so I'm starting a new thread to hopefully get updates from itch support on status of implementation in the future.

For reference, SharedArrayBuffer is a Javascript object used to share a memory space across threads on a website. This is used by frameworks such as Godot(with threading enabled) and love.js. To enable SharedArrayBuffer, two headers to enable cross origin isolation are required from itch.io.

Here are some previous threads on the topics:

https://itch.io/t/1339232/implement-headers-to-use-sharedarraybuffers-in-firefox-and-chrome-in-the-future

https://itch.io/t/1028526/cross-origin-policies-for-webassembly

https://itch.io/t/1332996/cross-origin-isolation-to-unblock-wasm-sharedarraybuffers

https://itch.io/t/1696861/cross-origin-header-issue

Newgrounds has enabled these changes:

https://www.newgrounds.com/bbs/topic/1468978

Hopefully we'll get an update soon.

Thanks!

Hi, if there is still a per game policy for enabling this feature, I would really like it enabled for https://chickenpiegames.itch.io/light-sweep, which struggles without it. I tried to contact the support directly but received no answer.

(Also, I would like to let you know that your 4 links above all point to the same thread)

Safari just reenabled support for SharedArrayBuffers (https://webkit.org/blog/12140/new-webkit-features-in-safari-15-2/). So now Chrome, Safari, and Firefox all support SharedArrayBuffers provided the correct cross origin flags are set on the server.

I have also stubbed my toe on the SharedArrayBuffer problem and would like a way to enable the needed headers.

However, I also have some workaround ideas for those who are encountering this issue. They may or may not work for you and may or may not cause issues especially with audio.

SharedArrayBuffer seems to be used to share data between threads in multithreaded applications, so either designing an app with no multithreading and/or disabling pthreads in the WASM exporter may avoid the error.

Things to consider trying:

• If using Emscripten or any language to web exporter, see if there is an option to disable pthreads, multithreading, or similar
• Similar to above, see if there is a “compatibility” setting for export (this worked for me in a Love2D export to web via Love.js)
• I saw one suggestion to explicitly assign SharedArrayBuffer to ArrayBuffer as such in the index.html in a script element: SharedArrayBuffer = ArrayBuffer; . I guess this is worth a try, but it sure looks like it would break a lot of stuff to me.
• Advanced untried idea: For audio, consider signaling the browser and play audio in JavaScript instead of from WASM. This would require some non-trivial extra programming in both the JavaScript and in the WASM artifact