Closed Bug 1600068 Opened 3 months ago Closed 2 months ago

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

Categories

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

defect

Tracking

()

RESOLVED DUPLICATE of bug 1578070
Fission Milestone M4.1

People

(Reporter: edenchuang, Assigned: edenchuang)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

No description provided.

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.

Assignee: nobody → echuang
Status: NEW → ASSIGNED
Priority: -- → P1

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.

Attachment #9112540 - Attachment description: Implement ProcessSwitchingCallback mechanism → Implement ProcessSwitchingCallback
Fission Milestone: --- → M4.1
Attachment #9112536 - Attachment description: Add a new optional memeber ClientOpenWindowArgs.browsingContextId → Add a new optional member ClientOpenWindowArgs.browsingContextId

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.

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1578070
You need to log in before you can comment on or make changes to this bug.