Update windowIDs on the loadInfo after doing a cross-process redirect
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox71 | --- | fixed |
People
(Reporter: valentin, Assigned: edenchuang)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
In bug 1551601 we update the loadInfo in nsDocShell::OpenInitializedChannel with the correct browsingContext.
However, it seems likely that other loadInfo attributes also need to be updated, such as the windowIDs (and maybe clientInfo/controller/etc)
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Valentin, could you please look into this?
Assignee | ||
Comment 2•5 years ago
|
||
dom/serviceworkers/test/test_sanitize_domain.html
Assignee | ||
Comment 3•5 years ago
|
||
Following Mochitests are fail since ClientInfo is not propagated to the switching process.
dom/serviceworkers/test/test_sanitize_domain.html
dom/serviceworkers/test/test_eventsource_intercept.html
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 4•5 years ago
|
||
(In reply to Eden Chuang[:edenchuang] from comment #3)
Following Mochitests are fail since ClientInfo is not propagated to the switching process.
dom/serviceworkers/test/test_sanitize_domain.html
dom/serviceworkers/test/test_eventsource_intercept.html
Hi Eden, could you maybe point me in the right direction of how the ClientInfo should be propagated ?
From what I can tell, the same ClientInfo that is on the LoadInfo in ContentChild::RecvCrossProcessRedirect is set on the newly created channel in the new process. But I do see these messages in the output:
0:11.22 GECKO(8772) [Child 9102, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/icecold/mozilla-central/dom/serviceworkers/ServiceWorkerManager.cpp, line 2007
0:11.22 GECKO(8772) [Child 9102, Main Thread] WARNING: 'error.Failed()', file /home/icecold/mozilla-central/dom/serviceworkers/ServiceWorkerInterceptController.cpp, line 73
0:11.22 GECKO(8772) [Child 9102, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/icecold/mozilla-central/netwerk/protocol/http/InterceptedChannel.cpp, line 65
This makes me think that the problem here is that in the newly created process we don't have the right controller/SWManager (not 100% sure how SW works).
In any case, do you have an idea //how// we should update the clientInfo in the redirected process?
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
When Fission is on, loading a cross-origin iframe triggers process switching when calling the channel::OnStartReqeust.
If a ServiceWorker should intercept the loading, the interception setting is completed while opening the channel.
That means the service worker controls the ClientSource created by the old process.
After process switching completed, the new ClientSource will be created and resume the loading from the opened channel.
However, in the original code, we did not update the controlled Client in the ServiceWorkerManager.
And when loading the same origin subresource in the new process, it makes ServiceWorkerManager cannot find the correct ServiceWorker to perform the interception.
Assignee | ||
Updated•5 years ago
|
Pushed by rmaries@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4946569ae95b
Update the controlled client in ServiceWorkerManager after process switching r=asuth,valentin,perry
Comment 7•5 years ago
|
||
bugherder |
Description
•