This is a follow-up for bug 1172870 to address the case where firefox is running without a browser window.

We can run into this bug more often than previously thought. With an active private browsing window, firefox can receive notifications and run service workers but won't have a valid browser window for openWindow.

Comment on attachment 8744901 [details] [diff] [review] Use the hidden XUL window when no browser window is available for ServiceWorkerClients.openWindow. So I think we should somehow explicitly tell when it is ok to not have tabparent when sending BrowserFrameOpenWindow message from child side, and only use that for sw.openWindow case, at least for now. Should be a simple change, but could take a look at another patch.

Comment on attachment 8744902 [details] [diff] [review] Don't send the url to the parent process when opening new windows, because it is not actually used. Fun. nsWindowWatcher code is so great :/ Could we add an assertion to nsWindowWatcher::OpenWindowInternal that if aOpeningTab is non-null, aURL is null.

mike, you were thinking about cleaning up WW code. See the latter patch here as another example of the messiness of the code :)

Youch. Thanks for cleaning that up, catalinb.

(In reply to Olli Pettay [:smaug] from comment #4) > Comment on attachment 8744901 [details] [diff] [review] > Use the hidden XUL window when no browser window is available for > ServiceWorkerClients.openWindow. > > So I think we should somehow explicitly tell when it is ok to not have > tabparent when sending BrowserFrameOpenWindow message from child side, and > only use that for sw.openWindow case, at least for now. > Should be a simple change, but could take a look at another patch. I'm not sure I follow. Service Workers use the SendCreateWindow path. As far as I know, BrowserFrameOpenWindow is used only on Firefox OS and always expects a valid tabchild, which is enforced through asserts. Are you suggesting adding a flag that explicitly marks that (in the child) the call is coming from a sw instead of guessing based on whether aTabOpener is null or not?

This was fixed when the openWindow code was refactored with the rest of the API for clients.