Re-enable postMessage transferable for faster ArrayBuffer transfers about react-devtools-experimental

[bvaughn]

Hey Dan. Any info about what you were doing when this happened? (Any breakpoints set or anything?) Can you reproduce it?

[gaearon]

Nope, just happened randomly. :-(

[bvaughn]

I've seen this one before, but only when I had breakpoints set in the Chrome extension itself.

Regarding transferables, the postMessage docs say:

An optional array of Transferable objects to transfer ownership of. If the ownership of an object is transferred, it becomes unusable (neutered) in the context it was sent from and becomes available only to the worker it was sent to.

So it seems like some part of the DevTools code is referencing the array buffer somehow after it's been sent across the bridge. I'm not sure how this is happening though, because the flow of code is:

• renderer passes the array to the agent and immediately clears its reference
• Agent passes the array on to the Bridge but otherwise does nothing with it
• Bridge passes it to the "wall", maybe after a small delay– but it has not yet been serialized at this point so the delay should be okay
• "wall" passes it to postMessage as-is

I'm not sure where in this flow of code we could be accessing the array in any way after it had been neutered. The error message wording actually sounds like we're trying to send the same array buffer through twice, but I don't know how that would happen either.

Maybe someone else will have an idea here 😄

[bvaughn]

I've commented out the transferrable for now (c184493) which should avoid this issue. Would still like to figure out the cause so we can re-enable it for Firefox.

[gaearon]

Can we do if (!window.chrome) or something?

[sompylasar]

This may potentially be fixed with this cleanup: #229

[bvaughn]

This repository is being merged into the main React repo (github.com/facebook/react). As part of this, I am moving all issues to that repository as well and closing them here.

This issue has been relocated to:
facebook/react#16488