Closed Bug 1561706 Opened 5 years ago Closed 5 years ago

Update windowIDs on the loadInfo after doing a cross-process redirect

Categories

(Core :: DOM: Navigation, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla71
Fission Milestone M4
Tracking Status
firefox71 --- fixed

People

(Reporter: valentin, Assigned: edenchuang)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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)

Priority: -- → P3

Valentin, could you please look into this?

Fission Milestone: --- → M4
Flags: needinfo?(valentin.gosu)
Priority: P3 → P2

dom/serviceworkers/test/test_sanitize_domain.html

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

Assignee: nobody → valentin.gosu
Flags: needinfo?(valentin.gosu)

(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?

Flags: needinfo?(echuang)
Assignee: valentin.gosu → echuang
Status: NEW → ASSIGNED
Flags: needinfo?(echuang)

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.

Keywords: checkin-needed

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

Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: