Closed Bug 1218080 Opened 7 years ago Closed 4 years ago

Fix service workers openWindow when there's no available browser window

Categories

(Core :: DOM: Service Workers, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox44 --- wontfix

People

(Reporter: catalinb, Assigned: catalinb)

References

Details

Attachments

(2 files, 1 obsolete file)

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.
Summary: Fix service workers openWindow on mac os when there's no available browser window → Fix service workers openWindow when there's no available browser window
Assignee: nobody → catalin.badea392
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.
Attachment #8744901 - Flags: review?(bugs) → review-
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.
Attachment #8744902 - Flags: review?(bugs) → review+
mike, you were thinking about cleaning up WW code. See the latter patch here as another example of the messiness of the code :)
Flags: needinfo?(mconley)
Youch. Thanks for cleaning that up, catalinb.
Flags: needinfo?(mconley)
(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?
Keywords: leave-open
Priority: -- → P3
This was fixed when the openWindow code was refactored with the rest of the API for clients.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.