1600068 - When process switching happen during Clients::OpenWindow, WebProgressListener should also be switched to the new target process.

Status: RESOLVED DUPLICATE of bug 1578070

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

Comment 1

[Eden Chuang[:edenchuang]]

dom/serviceworkers/test/test_openWindow fail when fission on.

When executing Clients::OpenWindow, ClientOpenWindowUtils register a WebProgressListener on target docShell to check the opened doc original URI, and return correct ClientOpResponse to the parent. However, when fission is on, the registered WebProgressListener will got STOP state because of process switching and make the test fail.

The solution idea is we should also let the registering the WebProgressListener again after process switching finish.

Comment 2

[Eden Chuang[:edenchuang]]

Attachment: Create a new return type ClientOpPendingByProcessSwitching for ClientOpResult

The WebProgressListener registered by ClientOpenWindowUtils::WaitForLoad could receive the STATE_STOP with "about:blank" document URI because of process switching.

This patch creates a new return type ClientOpResult::ClientOpPendingByProcessSwitching for the case and sends it back to the parent process.
The created BrowsingContextId for the document loading will be sent back to the parent process with ClientOpPendingByProcessSwitching by calling ClientOpenWindowOpChild::Send__delete__().
The ClientOpenWindowArgs, BrowsingContextId and the ClientOpPromise should be saved in the parent process for re-creating the ClientOpenWindowOpParent/Child in the correct content process.

Comment 3

[Eden Chuang[:edenchuang]]

Attachment: Add a new optional member ClientOpenWindowArgs.browsingContextId

Comment 4

[Eden Chuang[:edenchuang]]

Attachment: Implement ProcessSwitchingCallback

Comment 5

[Eden Chuang[:edenchuang]]

Attachment: Implement OpenWindowProcessSwitchingCallback for Clients.openWindow

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

I think we just want the planned solution in bug 1578070, so I'm going to dupe over to that bug. That is, my understanding is that the complexity here is because the Clients API attempts to open a window in a content process because it didn't think it could do it in the parent. The open request is not one that can complete in that same content process and so a process switch happens. The intent of the fix in bug 1578070 is to let openWindow just be initiated in the parent, building on DocumentChannel to determine the actual process in which to perform the open. This avoids a bunch of extra (confusing!) complexity.