It took us quite an effort to move away from that and now we revive things manually wherever we need it. @jrieken can fill in more details if I missed anything.

Yeah, all of that is gone (and the reason us using URI.revive a lot). Tho, it was a good change because recursively walking all objects that are being send is expensive. From the looks it seems that your solution doesn't require such a walk so that you can find and replace TypedArray instances.

For web, it would be great if we could mark any TypedArrays in postMessage as transferable to improve performance for large arrays. I believe this would require some changes in our core RPC code. I think we are already using transferable with here

On top of that we should investigate if message ports can be used. With that we could connect webviews directly to the extension host and wouldn't need to go through the renderer anymore. (I have done that with the web extension host that is launched through an iframe). Electron now supports MessagePorts between the main and renderer processes (@bpasero explored this for the shared process) and we should figure out if message ports would also work between webview processes and the extension host. Iff so then you would use our RPC only to exchange the ports and use a direct channel from then on

Iff so then you would use our RPC only to exchange the ports and use a direct channel from then on

👍 x 💯

On top of that we should investigate if message ports can be used. With that we could connect webviews directly to the extension host and wouldn't need to go through the renderer anymore.

I like the idea of exploring this but please keep in mind that with the sandbox architecture, the extension host process maybe something different than what it is today. Today it is a child process of the renderer but in the future it might even just be a normal node.js process.

I am not entirely sure if node.js supports the same concepts (found this: https://nodejs.org/api/worker_threads.html#worker_threads_class_messageport)

PS: we ship with message ports for renderer <-> shared process communication for this stable release and it has proven to be very stable so far.

I like the idea of exploring this but please keep in mind that with the sandbox architecture, the extension host process maybe something different than what it is today.

I think that's a very similar question. In the sandbox world how do renderers communicate with the extension host? Replaying messaging on the main-process, use web sockets, or message ports?

I think that's a very similar question. In the sandbox world how do renderers communicate with the extension host? Replaying messaging on the main-process, use web sockets, or message ports?

This is something that @deepak1556 will start to explore this month. From the sandbox backlog:

I think whatever solution we pick, it cannot go through electron-main but must be a direct communication channel.

Thanks for the feedback @alexdima! I'll continue exploring making this change in the webview code. I will also look into the our marshaling code to see if I can reuse some functions sheer

@jrieken I investigated using message port as well. I think using them should be possible but it requires some more thought for webviews.

In addition to the issues @bpasero brought up, the webview context is destroyed whenever the webview is hidden. This means that every time the webview is recreated (such as switching back to a custom editor), we'd have to go through the message port exchange again. Instead of waiting for this to complete before sending any messages, I think we could do something like:

1. Webview is recreated
2. We start passing the message port from the webview to the extension host
3. If postMessage is called during this time, we pass those messages through the existing flow (extension host -> main -> webview)
4. Once the extension host receives the message port, we start using it instead

I'll merge this at the start of April for more testing