ServiceWorkerManager must check for ongoing shutdown to avoid its resurrection
Categories
(Core :: DOM: Service Workers, defect, P3)
Tracking
()
People
(Reporter: jstutte, Unassigned)
References
Details
The ServiveWorkerManager singleton's static functions can be called even during late shutdown. But once we have shut it down and cleared its global, we should not accept any further invocation but throw an error.
See bug 1709184 comment 2 and following for more context.
|
||
Updated•4 years ago
|
|
Reporter | |
Comment 1•4 years ago
|
||
ServiceWorkerManager::GetInstance has been hardened already in bug 1726813. AFAICS all uses of ServiceWorkerManager start with ServiceWorkerManager::GetInstance and the returned pointer is never set aside into some long-living variable or object.
So I think there should be nothing left to do if not look out for unhandled exceptions if we return nullptr.
If we want to be 110% sure against shutdown races we should check each public entrypoint of ServiceWorkerManager for long running operations that might overlap with the beginning of the shutdown. asuth, do you expect this to be a potential problem?
|
|
||
Comment 2•4 years ago
|
||
Yes, we can probably resolve this bug. And in our pair analysis, we noticed that maybe we need a bug covering handling calls to ServiceWorkerManager::GetInstance() in the content process and asserting hard in that case, noting that there may be some leftover calls from things like devtools. I think this was notionally a work item for cleanup following the switch to parent-intercept only.
|
|
Reporter | |
Updated•4 years ago
|
Description
•