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

Boris Zbarsky wrote:
> 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).
> 

OK.  Modulo the bug with 'rpc' and ctors not playing well together, I 
think window.open (is this createWindow() in PIFrameEmbedding?) can be 
'sync'.  I'm working on fixing this bug right now.

> 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.
> 

No thanks :).  I think 'sync'++ is the right choice here.

Cheers,
Chris