Originally, exposure of APIs to JS was done using the XPConnect JS/XPCOM bridge in Firefox. Simplifying a little, XPConnect is not thread-safe, so exposing APIs to workers required manually writing code using the SpiderMonkey JS API. This was done in an ad-hoc fashion for a while. Additionally, XPConnect allowed JS code to be written to expose functionality to content on the main thread, but was basically a non-starter on the worker thread because of the lack of XPConnect. (Simplifying slightly again, XPConnect also provided required security protections.)

Between having to write thread-safe code and custom JS exposure, the overhead could be significant. This has now been greatly improved through the use of automatically generated WebIDL bindings, although C++ is still used and threading issues do have to be dealt with (usually by remoting a runnable to the main thread), so worker versions of an API still aren't free.

New Web APIs implemented by the platform team should usually be designed from the ground-up for worker exposure and have worker support land soon-after or at the same time as the main-thread support. Experimental APIs related to Firefox OS and developed by Firefox OS Gaia teams are more likely to be prototypes implemented in JS for rapid prototyping and will need another rev before they can be exposed to workers. This last bit frequently happens as part of an effort to standardize the API informed by the prototype.

Links for context: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/... https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bind...

Thank you very much for your explanation!

We ended up writing a goofy little console.log() replacement that sent messages back to the main UI thread for processing and logging, but that kind of thunking is a might-bit janky.

The console.log exposed to workers just sends the messages to the UI thread for logging...

I forget whether the workaround was done for Firefox or Chrome...I remember hitting it in one or the other, and putting in the workaround for both.

On a related note, transferable objects are handled a bit differently between IE, FF, and Chrome. Some are a bit stricter than others.

That's not surprising, but annoying. Please do file bugs as needed; the spec is generally pretty clear about how things should work here, so if browsers don't agree one of them is just buggy.

Cause printing functions usually aren't thread safe I'd assume it has to be a similar reason.

According to comments in that bug it looks like it were held up due to discussion around standardization of the Console API and a rewrite of the same.

https://bugzilla.mozilla.org/show_bug.cgi?id=620935#c30

The Console API is getting rewritten to handle proper console.logging with colours, grouping etc.