Re: RFC: Electrolysis manifesto: Chrome never blocks on content

On 4/23/10 3:16 PM, Chris Jones wrote:
> If ctors are the only reason we're using RPC, I say it's a semantic bug
> that we should fix. There are several ways we can special-case actor
> ctors. I'll file a bug.

The reason I used rpc most recently was to support window.open.

For window.open, what needs to happen is that content code asks chrome 
for a new window.  Chrome calls back into the content process and has it 
create a window, then hands that window to the original caller.

In terms of the actual messages on the wire, content sends a "give me a 
window" message, chrome JS creates a <xul:browser>, whatever stuff 
happens to create a new content process rendering area happens, then 
chrome sends back the TabParent (which becomes a TabChild on the content 
side).

I suppose we could change this by having the messages involved be async 
but content spinning a (nested) event loop manually to prevent returning 
to the open() caller...  Would that work?  Seems kinda fragile, but 
maybe so's rpc.

-Boris