1129884 - It should be possible transfer typed arrays from add-on code to content script

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Matteo Ferretti [:zer0] [:matteo]]

I didn't find an easy way to transfer a typed array from an add-on code, to a content script.

IMVHO, we should either:

- fix the `worker.postMessage` / `worker.port.emit` in order to handle typed array (high level API solution)
- add a function to retrieve a sandbox from a `worker`,so we should be able to use `cloneInto` using that as target (low level API solution)

It would be nice actually to have both – the second one could be used for other stuff too.

Comment 1

[Erik Vold [:erikvold] (please needinfo? me)]

I think we should just stick to supporting whatever JSON.parse/stringify supports, I'm not sure why we need to support typed arrays here, Irakli should decide this high-level change though.

Comment 2

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to Erik Vold [:erikvold] (please needinfo? me) from comment #1)
> I think we should just stick to supporting whatever JSON.parse/stringify
> supports,

I think we should supporting whatever the web standard supports for the `postMessage`; our `postMessage` should be the same, not something different. We use JSON here, but it's not correct: instead, we should use the same algorithm of regular `postMessage` (https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/The_structured_clone_algorithm) and offers the same capabilities.

> I'm not sure why we need to support typed arrays here, Irakli
> should decide this high-level change though.

Because without the proper support of typed arrays, we can't do a lot of interesting stuff that deal with complex data – I discovered that limitation during an add-on I was working on –, plus the performance. And not mentioning that as developer, I'm expecting a consistent behavior with web API – and, because it's privileged code, I wouldn't expect more limitation than a web page.

Comment 3

[Erik Vold [:erikvold] (please needinfo? me)]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #2)
> (In reply to Erik Vold [:erikvold] (please needinfo? me) from comment #1)
> > I think we should just stick to supporting whatever JSON.parse/stringify
> > supports,
> 
> I think we should supporting whatever the web standard supports for the
> `postMessage`; our `postMessage` should be the same, not something
> different. We use JSON here, but it's not correct: instead, we should use
> the same algorithm of regular `postMessage`
> (https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/
> The_structured_clone_algorithm) and offers the same capabilities.

I thought we're deprecating `postMessage`.

> > I'm not sure why we need to support typed arrays here, Irakli
> > should decide this high-level change though.
> 
> Because without the proper support of typed arrays, we can't do a lot of
> interesting stuff that deal with complex data – I discovered that limitation
> during an add-on I was working on –, plus the performance. And not
> mentioning that as developer, I'm expecting a consistent behavior with web
> API – and, because it's privileged code, I wouldn't expect more limitation
> than a web page.

Can you please elaborate on this use case?

Comment 4

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to Erik Vold [:erikvold] (please needinfo? me) from comment #3)

> (In reply to Matteo Ferretti [:matteo] [:zer0] from comment #2)
> > (In reply to Erik Vold [:erikvold] (please needinfo? me) from comment #1)
> > > I think we should just stick to supporting whatever JSON.parse/stringify
> > > supports,
> > 
> > I think we should supporting whatever the web standard supports for the
> > `postMessage`; our `postMessage` should be the same, not something
> > different. We use JSON here, but it's not correct: instead, we should use
> > the same algorithm of regular `postMessage`
> > (https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/
> > The_structured_clone_algorithm) and offers the same capabilities.

> I thought we're deprecating `postMessage`.

Even if we deprecate `postMessage` (and I'm not aware of it), we'll still have a mechanism to send messages between compartments. Such mechanism shouldn't be more limited than the web standards. In the web standards such mechanism both window's postMessage and worker's postMessage gives the capability to send typed arrays, because they use the structured clone algorithm, that has advantages on JSON – see the link above.

Also the MessageManager in e10s uses that. I'm honestly don't understand why we should behave differently – and more limited – than everyone else.

> > Because without the proper support of typed arrays, we can't do a lot of
> > interesting stuff that deal with complex data – I discovered that limitation
> > during an add-on I was working on –, plus the performance. And not
> > mentioning that as developer, I'm expecting a consistent behavior with web
> > API – and, because it's privileged code, I wouldn't expect more limitation
> > than a web page.

> Can you please elaborate on this use case?

Reading a file / stream from file system o remote web site (dynamic domains, so no permissions to set, easily to avoid the cross origin policy just makes the XHR from add-on side) and send the data to the content script. In my case it was a mod / xm file.
Also, as I said, it's a question about performance. A lot of optimization can be made using typed arrays (https://developer.mozilla.org/en/docs/Web/JavaScript/Typed_arrays), when you deal with binary data.

Comment 5

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

I agree, we need to support typed arrays, they were designed to optimise transfer of big data chunks thread / process boundaries. Sending binary data by serialising to JSON and parsing it again is really sub-optimal.

Zero would you be able to work on this ?

Also for a while I wanted to replace our custom port implementation with a standard `MessagePorts` maybe it's a good opportunity to introduce them as a solution for passing binary data and in general try to migrate folks over.

Comment 6

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1399562