As raised in https://bugzilla.mozilla.org/show_bug.cgi?id=1130687#c36, we will need to deal with the different scenarios independently, so opening this bug to track FirefoxOS one.

Add the component in charge of open window

The patch sends a 'content-handler' async message to parent, which is processed to call view activity and open a new browser window. The main problem is how to return the reference of the new window to gecko? I tried to create a new activity with a return value to send back the window object of the 'AppWindow' created in system/js/browser.js but it is a XPCOM object that can not be serialized in the activity response (As it doesn't work I don't include the code in the WIP). I also tried to send a mozChromeEvent from the component to gaia but it fails because SystemAppProxy._sendCustomEvent can't send the event as the frame is null. However, I am going to have the same problem to send back the window reference through the mozContentEvent. Can you give some advice about how to proceed?

Albert, looks at what we do for the mozbrowseropenwindow event from the mozbrowser api. That looks like a very similar use case.

(In reply to Fabrice Desré [:fabrice] from comment #3) > Albert, looks at what we do for the mozbrowseropenwindow event from the > mozbrowser api. That looks like a very similar use case. I've look the mozbrowseropenwindow, it works and seems a better approach than using the activity. However I see that when setting '_blank' name it reuses the browser and navigate to the new url instead of opening a new one. If I set another name it opens a new browser window in background. I guess I need to explore a bit more the event details to fix it, but the main problem is that I can't still get a reference to the new window as happens with the activity approach.

Albert, do we want to always open this window in the same process as the caller? I guess OpenWindow() is a sync call also?

(In reply to Fabrice Desré [:fabrice] from comment #5) > Albert, do we want to always open this window in the same process as the > caller? I guess OpenWindow() is a sync call also? Yes, at least in desktop environment it is a requisite. Currently is a sync call but talking with andreas we agree that I have to move to async, as I have to return a promise it won't be a problem.

Sorry Albert, I'm still struggling a bit with this one. Is that correct: 1- We load site http://example.com, in processA 2- example.com runs a service worker, worker.js 3- worker.js calls openWindow('page.html') 4- we need to return a promise that resolves to the new window, running it in the same processA. If so, I don't think we have the pieces we need right now. We need the ContentChild to create a new TabChild/TabParent pair, load page.html in it, and somehow notify gaia's system app that we have a new window to deal with. That's... interesting!

(In reply to Fabrice Desré [:fabrice] from comment #7) > Sorry Albert, I'm still struggling a bit with this one. Is that correct: > > 1- We load site http://example.com, in processA > 2- example.com runs a service worker, worker.js > 3- worker.js calls openWindow('page.html') > 4- we need to return a promise that resolves to the new window, running it > in the same processA. > > If so, I don't think we have the pieces we need right now. We need the > ContentChild to create a new TabChild/TabParent pair, load page.html in it, > and somehow notify gaia's system app that we have a new window to deal with. > That's... interesting! Yes you are right, the main problem is about opening a without a parent. Have a look to https://bugzilla.mozilla.org/show_bug.cgi?id=1130687#c51 guidelines for desktop.

Yep, you should sync up with Bill to come up with something that also works for b2g.

Releasing it, please ni me if you need some feedback.