1742886 - Fix races between two parent-process initiated loads

Status: NEW

(Core :: DOM: Navigation, task, P3)

Description

[Anny Gakhokidze [:annyG]]

Details to be added!

Comment 1

[Anny Gakhokidze [:annyG]]

In patch https://phabricator.services.mozilla.com/D131263, I changed the test in order to avoid a race between loads, but it was a fix for a test, and did not fix the underlying race. The test times out here.

In the later part of the test, we load https://example.org/browser/browser/base/content/test/general/dummy_page.html (TEST_PAGE uri) first, and then, without waiting for the TEST_PAGE load to complete (in the original version of the test) we trigger the load for about:mozilla in the same browser. What happens is that the TEST_PAGE load ends up cancelling the later about:mozilla one, and we time out because we are waiting for the about:mozilla load to complete.
(same numbers indicate events that might happen around the same time)

1. [parent] We trigger TEST_PAGE load in the parent. Because CanonicalBrowsingContext::SupportsLoadingInParent returns true for this URI, then we proceed with this load in the parent process.
2. [parent] We trigger about:mozilla load in the parent. However, CanonicalBrowsingContext::SupportsLoadingInParent returns false . So we bounce the load to the content process.
3. [content process] We call nsDocShell::InternalLoad to start loading the about:mozilla URI

• 🌸 see below
• [content process] We create a DocumentChannelChild for the about:mozilla load
• [parent process] We create a DocumentChannelParent for the about:mozilla load
• [parent process] The load gets cancelled somewhere here because of 🐮🐮 (see the call below)

3. [content process] The parent redirected the TEST_PAGE load to the final content process, and we start loading it in the docshell.

• [content process] TEST_PAGE load ends up cancelling about:mozilla load as a result of 🐮🐮 this call.

🌸Even though at this point in nsDocShell::InternalLoad we are able to cancel other loads, either here or here, I think the redirection of TEST_PAGE from the parent process into the content process hasn't occurred yet.

I've tried experimenting with cancelling all loads in DocumentChannelChild, but it didn't work out because it ended up cancelling the load itself. I also tried a few other solutions such as using the load identifier on the Browsing Context, but it is process specific and just because one identifier is higher than the other one, does not mean it is the latest load.

Nika suggested that we might want to look into implementing cross process LoadGroups.

Comment 2

[Anny Gakhokidze [:annyG]]

On the priority - this doesn't have to be fixed in order for the parent controlled pref to be enabled, because patch https://phabricator.services.mozilla.com/D131263 (landed) fixes the test. So to start reproducing the race between the parent and the content process loads, you need to remove the fix I added. Sometimes you have to do it in a verify mode, if you can't reproduce it in a single test run. I was able to reproduce it on my linux machine.