We currently return false from shouldLoadURI when we the current uri is about:newtab (and it's the only entry in session history), under the assumption that this "web" process is likely a preloaded browser process.

I think this is fairly rare now, since about:newtab is usually in the privileged content process, but we disable this pref on ASAN builds.

This caused a failure with parent-initiated loads, where we initiated the load speculatively in the parent, but then the content process cancelled it (due to shouldLoadURI being false), and then started it again in another process. The test (browser_google_behavior) is using waitForDocLoadAndStopIt to cancel loads before they try to hit the network (and assert), but this fails to catch the second load.

We're trying to move away from using shouldLoadURI for process switches (since it can't handle POST data, and it's nicer to have everything rely on DocumentChannel), so fixing this seems worthwhile (rather than modifying the test to work around it).

Note that when about:newtab is loaded in the privileged content process, we don't need any special case handling since normal URIs will compute a different remote type and be processed switched.

It appears that we currently don't do these switches if there is POST data, so maybe we could just stop doing them entirely, and relying on the privileged content process to be enabled for all configurations we care about?

https://hg.mozilla.org/mozilla-central/rev/3dcd50f429d9