For instance, I got:
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_getSecurityInfo.js | Test timed out -
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_getSecurityInfo.js | Found a tab after previous test timed out: about:blank -
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_identityIcon_img_url.js | Test timed out -
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_identityIcon_img_url.js | Found a tab after previous test timed out: about:blank -
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_mixed_content_cert_override.js | Test timed out -
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_mixed_content_cert_override.js | Found a tab after previous test timed out: about:blank -
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_mixed_content_with_navigation.js | Test timed out -
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_mixed_content_with_navigation.js | Found a tab after previous test timed out: about:blank -
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_navigation_failures.js | Test timed out -
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_navigation_failures.js | Found a tab after previous test timed out: https://example.com/browser/browser/base/content/test/siteIdentity/dummy_page.html -
TEST-UNEXPECTED-FAIL | browser/base/content/test/siteIdentity/browser_navigation_failures.js | Uncaught exception received from previously timed out test -

From the log, I saw:

[task 2019-11-22T14:47:15.820Z] 14:47:15 INFO - GECKO(1530) | JavaScript error: resource:///modules/sessionstore/SessionStore.jsm, line 2710: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIProcessSwitchRequestor.crossOriginOpenerPolicy]

Not sure if it's related to the failure atm.

Valentin, you probably have more idea than I do about what's going on?

I can reproduce these on my Mac. Please let me know if you want more information. Thanks!

diff --git a/netwerk/protocol/http/nsHttpChannel.cpp b/netwerk/protocol/http/nsHttpChannel.cpp
--- a/netwerk/protocol/http/nsHttpChannel.cpp
+++ b/netwerk/protocol/http/nsHttpChannel.cpp
@@ -7292,7 +7292,8 @@ nsHttpChannel::GetCrossOriginOpenerPolic
   // ComputeCrossOriginOpenerPolicy) or if we were unable to compute the
   // policy we'll throw an error.
   if (!mComputedCrossOriginOpenerPolicy.isSome()) {
-    return NS_ERROR_NOT_AVAILABLE;
+    *aPolicy = nsILoadInfo::OPENER_POLICY_NULL;
+    return NS_OK;
   }
   *aPolicy = mComputedCrossOriginOpenerPolicy.value();
   return NS_OK;

This patch fixed the error, but the tests still time out. I think the tests may not be able to able to deal with a process switch.

This blocks a P1 bug. Valentin, can you look at this or do you know who could help here?

Hey Tom,

I still see the Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIProcessSwitchRequestor.crossOriginOpenerPolicy] line in the output, but the tests now pass and no longer time out.

I'm running:
./mach test browser/base/content/test/siteIdentity/browser_navigation_failures.js --setpref browser.tabs.remote.useCORP=true --setpref browser.tabs.remote.useCrossOriginOpenerPolicy=true --setpref browser.tabs.remote.useCrossOriginEmbedderPolicy=true --setpref dom.postMessage.sharedArrayBuffer.withCOOP_COEP=true --headless

I'm assuming another fix has solved this too.
Can you check and let me know if they now pass for you?
Thanks!

Will run that locally and push the latest m-c with patches. I will reply here when I get the result for that. Thanks!

There are still some tests timed out. Not sure if the causes are the same or different.

TEST-UNEXPECTED-FAIL | dom/security/test/csp/test_uir_top_nav.html | Test timed out

I can reproduce this on my Mac with ./mach test dom/security/test/csp/test_uir_top_nav.html --setpref browser.tabs.remote.useCrossOriginOpenerPolicy=true --setpref browser.tabs.remote.useCrossOriginEmbedderPolicy=true --headless
Maybe, I need to turn some other prefs to avoid timing out?

The log:

 0:51.76 TEST_START: dom/security/test/csp/test_uir_top_nav.html
 0:57.86 GECKO(90443) ++DOMWINDOW == 6 (0x139261400) [pid = 90445] [serial = 7] [outer = 0x14128c3e0]
 0:57.87 GECKO(90443) [Parent 90443, Main Thread] WARNING: we only accept nsIURI interface type, patch welcome: file /Users/tomtung/Work/mozilla-central/dom/ipc/PropertyBagUtils.cpp, line 112
 0:57.87 GECKO(90443) ++DOMWINDOW == 7 (0x141269c00) [pid = 90445] [serial = 8] [outer = 0x14128c3e0]
 0:57.87 GECKO(90443) ++DOCSHELL 0x141415000 == 3 [pid = 90445] [id = {fce658f2-2204-6d4f-8297-8e3bdcc13d4c}]
 0:57.87 GECKO(90443) ++DOMWINDOW == 8 (0x14128c5c0) [pid = 90445] [serial = 9] [outer = 0x0]
 0:57.87 GECKO(90443) ++DOMWINDOW == 9 (0x1414cec00) [pid = 90445] [serial = 10] [outer = 0x14128c5c0]
 0:57.87 GECKO(90443) ++DOMWINDOW == 10 (0x1392d9800) [pid = 90445] [serial = 11] [outer = 0x14128c5c0]
 0:57.87 GECKO(90443) --DOMWINDOW == 6 (0x11814a400) [pid = 90446] [serial = 12] [outer = 0x0] [url = moz-extension://d943356c-af9c-5546-a532-9561a2ee6e48/_generated_background_page.html]
 0:57.87 GECKO(90443) ++DOCSHELL 0x1392b5000 == 4 [pid = 90445] [id = {5ff5b5bb-edb3-6040-b13e-95ae018c9828}]
 0:57.87 GECKO(90443) ++DOMWINDOW == 11 (0x14128cb60) [pid = 90445] [serial = 12] [outer = 0x0]
 0:57.87 GECKO(90443) --DOMWINDOW == 9 (0x192888c00) [pid = 90443] [serial = 9] [outer = 0x0] [url = about:blank]
 0:57.87 GECKO(90443) --DOMWINDOW == 8 (0x192887400) [pid = 90443] [serial = 8] [outer = 0x0] [url = about:blank]
 0:57.87 GECKO(90443) ++DOMWINDOW == 12 (0x1a7f34800) [pid = 90445] [serial = 13] [outer = 0x14128cb60]
 0:57.87 GECKO(90443) [Child 90445, Main Thread] WARNING: '!aWin', file /Users/tomtung/Work/mozilla-central/dom/base/Document.cpp, line 1384
 0:57.87 GECKO(90443) [Child 90445, Main Thread] WARNING: '!aWin', file /Users/tomtung/Work/mozilla-central/dom/base/Document.cpp, line 1384
 0:58.55 GECKO(90443) [Child 90445, Main Thread] WARNING: NS_ENSURE_TRUE(mRequest) failed: file /Users/tomtung/Work/mozilla-central/netwerk/base/nsBaseChannel.cpp, line 902
 0:58.55 GECKO(90443) [Child 90445, Main Thread] WARNING: NS_ENSURE_TRUE(mRequest) failed: file /Users/tomtung/Work/mozilla-central/netwerk/base/nsBaseChannel.cpp, line 902
 0:58.64 GECKO(90443) [2019-11-29T16:49:01Z WARN  rkv::backend::impl_safe::environment] Ignoring `map_size=16777216`
 0:58.71 GECKO(90443) [Parent 90443, Main Thread] WARNING: we only accept nsIURI interface type, patch welcome: file /Users/tomtung/Work/mozilla-central/dom/ipc/PropertyBagUtils.cpp, line 112
 0:58.95 GECKO(90443) ++DOMWINDOW == 13 (0x1a7f3cc00) [pid = 90445] [serial = 14] [outer = 0x14128cb60]
 0:59.09 GECKO(90443) ++DOCSHELL 0x1a7f06000 == 5 [pid = 90445] [id = {c5290dc3-9ebd-d54d-ada1-5d1de04f864a}]
 0:59.09 GECKO(90443) ++DOMWINDOW == 14 (0x14128d880) [pid = 90445] [serial = 15] [outer = 0x0]
 0:59.09 GECKO(90443) ++DOMWINDOW == 15 (0x1a7ff8c00) [pid = 90445] [serial = 16] [outer = 0x14128d880]
 0:59.61 GECKO(90443) ++DOMWINDOW == 16 (0x1a802c400) [pid = 90445] [serial = 17] [outer = 0x14128d880]
 0:59.69 GECKO(90443) ++DOCSHELL 0x1a800d000 == 6 [pid = 90445] [id = {4773cf0f-8a10-fa49-bf8b-3bc3abc07c0c}]
 0:59.69 GECKO(90443) ++DOMWINDOW == 17 (0x14128da60) [pid = 90445] [serial = 18] [outer = 0x0]
 0:59.70 GECKO(90443) ++DOMWINDOW == 18 (0x1a8031400) [pid = 90445] [serial = 19] [outer = 0x14128da60]
 1:00.02 GECKO(90443) --DOMWINDOW == 17 (0x1a4d4fc00) [pid = 90445] [serial = 6] [outer = 0x0] [url = about:blank]
 1:00.02 GECKO(90443) --DOMWINDOW == 16 (0x136c18800) [pid = 90445] [serial = 3] [outer = 0x0] [url = about:blank]
 1:00.57 GECKO(90443) ++DOMWINDOW == 17 (0x13a746c00) [pid = 90445] [serial = 20] [outer = 0x14128da60]
 1:01.14 GECKO(90443) [Parent 90443, Main Thread] WARNING: we only accept nsIURI interface type, patch welcome: file /Users/tomtung/Work/mozilla-central/dom/ipc/PropertyBagUtils.cpp, line 112
 1:01.23 GECKO(90443) ++DOMWINDOW == 18 (0x1a4dd4000) [pid = 90445] [serial = 21] [outer = 0x14128da60]
 1:01.42 PASS same origin should be upgraded to https, cross origin should remain http
 1:01.67 GECKO(90443) [Child 90445, Main Thread] WARNING: Trying to request nsIHttpChannel from DocumentChannelChild, this is likely broken: file /Users/tomtung/Work/mozilla-central/netwerk/ipc/DocumentChannelChild.cpp, line 60
 1:01.67 GECKO(90443) ++DOCSHELL 0x138b4d800 == 1 [pid = 90447] [id = {6f47e905-a974-b842-b107-3f86bc133398}]
 1:01.67 GECKO(90443) [Child 90445, Main Thread] WARNING: Trying to request nsIHttpChannel from DocumentChannelChild, this is likely broken: file /Users/tomtung/Work/mozilla-central/netwerk/ipc/DocumentChannelChild.cpp, line 60
 1:14.24 GECKO(90443) [Child 90445, Main Thread] WARNING: NS_ENSURE_TRUE(request) failed: file /Users/tomtung/Work/mozilla-central/netwerk/base/nsLoadGroup.cpp, line 575
 1:14.24 GECKO(90443) ++DOMWINDOW == 1 (0x16d34c020) [pid = 90447] [serial = 1] [outer = 0x0]
 1:14.24 GECKO(90443) [Child 90447, Main Thread] WARNING: NS_ENSURE_TRUE(mPresShell) failed: file /Users/tomtung/Work/mozilla-central/layout/base/nsPresContext.cpp, line 848
 1:14.24 GECKO(90443) ++DOMWINDOW == 2 (0x18f6f6c00) [pid = 90447] [serial = 2] [outer = 0x16d34c020]
 1:14.25 GECKO(90443) [Parent 90443, Main Thread] WARNING: we only accept nsIURI interface type, patch welcome: file /Users/tomtung/Work/mozilla-central/dom/ipc/PropertyBagUtils.cpp, line 112
 1:14.25 GECKO(90443) ++DOMWINDOW == 3 (0x18f6fac00) [pid = 90447] [serial = 3] [outer = 0x16d34c020]
 1:14.25 GECKO(90443) [90449, MainThread] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /Users/tomtung/Work/mozilla-central/xpcom/base/nsTraceRefcnt.cpp, line 198
 1:14.25 GECKO(90443) [90449, MainThread] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /Users/tomtung/Work/mozilla-central/xpcom/base/nsTraceRefcnt.cpp, line 198
 1:14.25 GECKO(90443) ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /var/folders/cx/66pl2zlj7qx02hpcmdyps_hc0000gn/T/tmpr1XGOS.mozrunner/runtests_leaks_tab_pid90449.log
 1:14.25 GECKO(90443) [90449, MainThread] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /Users/tomtung/Work/mozilla-central/xpcom/base/nsTraceRefcnt.cpp, line 198
 1:14.25 GECKO(90443) [90449, MainThread] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /Users/tomtung/Work/mozilla-central/xpcom/base/nsTraceRefcnt.cpp, line 198
 1:14.25 GECKO(90443) [Child 90449, Main Thread] WARNING: No CID found when attempting to map contract ID: file /Users/tomtung/Work/mozilla-central/xpcom/components/nsComponentManager.cpp, line 729
 1:14.25 GECKO(90443) JavaScript error: https://example.com/tests/dom/security/test/csp/file_uir_top_nav_dummy.html, line 7: TypeError: window.opener is null

The suspicious part is Trying to request nsIHttpChannel from DocumentChannelChild, this is likely broken: file /Users/tomtung/Work/mozilla-central/netwerk/ipc/DocumentChannelChild.cpp, line 60. I also found many failing tests have error like: TypeError: window.opener is null.

Some other test timed out I notice:
TEST-UNEXPECTED-FAIL | toolkit/components/extensions/test/mochitest/test_ext_webrequest_filter.html | Test timed out.
TEST-UNEXPECTED-FAIL | dom/security/test/csp/test_uir_windowwatcher.html | Test timed out.

I wonder if both Bug 1600326 and this bug are caused by process switching issue.

Hi Tom,

I added an NS_ASSERTION to the failed QI in the DocumentChannel, and this is what I got:

#01: nsQueryInterfaceISupportsWithError::operator()(nsID const&, void**) const (mozilla-central/xpcom/base/nsCOMPtr.cpp:?)
 #02: void nsCOMPtr<nsIHttpChannel>::assign_from_qi_with_error<nsIRequest>(nsQueryInterfaceWithError<nsIRequest> const&, nsID const&) (mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nsCOMPtr.h:1176)
 #03: nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (mozilla-central/uriloader/base/nsURILoader.cpp:221)
 #04: mozilla::net::DocumentChannelChild::ShutdownListeners(nsresult) (mozilla-central/netwerk/ipc/DocumentChannelChild.cpp:243)
 #05: mozilla::net::DocumentChannelChild::Cancel(nsresult) (Unified_cpp_netwerk_ipc0.cpp:?)
 #06: mozilla::net::nsLoadGroup::Cancel(nsresult) (Unified_cpp_netwerk_base2.cpp:?)
 #07: nsDocLoader::Stop() (mozilla-central/uriloader/base/nsDocLoader.cpp:237)
 #08: nsDocShell::Stop(unsigned int) (mozilla-central/docshell/base/nsDocShell.cpp:4411)
 #09: non-virtual thunk to nsDocShell::Stop(unsigned int) (Unified_cpp_docshell_base0.cpp:?)
 #10: NS_InvokeByIndex (mozilla-central/xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:110)
 #11: CallMethodHelper::Call() (mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:1183)
 #12: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:1149)
 #13: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (mozilla-central/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:946)
 #14: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) (mozilla-central/js/src/vm/Interpreter.cpp:456)
 #15: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) (mozilla-central/js/src/vm/Interpreter.cpp:548)
 #16: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:?)
 #17: js::RunScript(JSContext*, js::RunState&) (mozilla-central/js/src/vm/Interpreter.cpp:423)
 #18: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) (mozilla-central/js/src/vm/Interpreter.cpp:589)
 #19: js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (mozilla-central/js/src/jit/BaselineIC.cpp:2940)
 #20: ??? (???:???)


 0:14.02 GECKO(21913) [Child 22001, Main Thread] WARNING: Trying to request nsIHttpChannel from DocumentChannelChild, this is likely broken: file mozilla-central/netwerk/ipc/DocumentChannelChild.cpp, line 60
 0:14.02 GECKO(21913) [Child 22001, Main Thread] ###!!! ASSERTION: test: 'false', file mozilla-central/netwerk/ipc/DocumentChannelChild.cpp, line 61
 #01: void nsCOMPtr<nsIHttpChannel>::assign_from_qi<nsIChannel>(nsQueryInterface<nsIChannel>, nsID const&) (mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nsCOMPtr.h:1162)
 #02: nsCOMPtr<nsIHttpChannel>::operator bool() const (mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nsCOMPtr.h:839)
 #03: nsDocShell::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, nsresult) (mozilla-central/docshell/base/nsDocShell.cpp:6066)
 #04: non-virtual thunk to nsDocShell::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, nsresult) (Unified_cpp_docshell_base0.cpp:?)
 #05: nsDocLoader::DoFireOnStateChange(nsIWebProgress*, nsIRequest*, int&, nsresult) (mozilla-central/uriloader/base/nsDocLoader.cpp:1352)
 #06: nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::Length() const (mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nsTArray.h:348)
 #07: RefPtr<nsDocLoader>::get() const (mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/mozilla/RefPtr.h:278)
 #08: nsDocLoader::OnStopRequest(nsIRequest*, nsresult) (mozilla-central/uriloader/base/nsDocLoader.cpp:619)
 #09: non-virtual thunk to nsDocLoader::OnStopRequest(nsIRequest*, nsresult) (Unified_cpp_uriloader_base0.cpp:?)
 #10: mozilla::net::nsLoadGroup::NotifyRemovalObservers(nsIRequest*, nsresult) (mozilla-central/netwerk/base/nsLoadGroup.cpp:595)
 #11: mozilla::net::nsLoadGroup::RemoveRequest(nsIRequest*, nsISupports*, nsresult) (Unified_cpp_netwerk_base2.cpp:?)
 #12: nsCOMPtr<nsILoadGroup>::assign_assuming_AddRef(nsILoadGroup*) (mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nsCOMPtr.h:412)
 #13: mozilla::net::DocumentChannelChild::Cancel(nsresult) (Unified_cpp_netwerk_ipc0.cpp:?)
 #14: mozilla::net::nsLoadGroup::Cancel(nsresult) (Unified_cpp_netwerk_base2.cpp:?)
 #15: nsDocLoader::Stop() (mozilla-central/uriloader/base/nsDocLoader.cpp:237)
 #16: nsDocShell::Stop(unsigned int) (mozilla-central/docshell/base/nsDocShell.cpp:4411)
 #17: non-virtual thunk to nsDocShell::Stop(unsigned int) (Unified_cpp_docshell_base0.cpp:?)
 #18: NS_InvokeByIndex (mozilla-central/xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:110)
 #19: CallMethodHelper::Call() (mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:1183)
 #20: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:1149)
 #21: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (mozilla-central/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:946)
 #22: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) (mozilla-central/js/src/vm/Interpreter.cpp:456)
 #23: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) (mozilla-central/js/src/vm/Interpreter.cpp:548)
 #24: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:?)

I think the second one, in DocShell means we don't fire the window.onload handler in file_uir_top_nav_dummy.html
I'm not exactly sure how we'd fix that one.

The failing QI is this one I think: https://searchfox.org/mozilla-central/rev/04d8e7629354bab9e6a285183e763410860c5006/docshell/base/nsDocShell.cpp#6297

I don't that affects anything other than the mLSHE->SetSaveLayoutStateFlag(false); call.

Ah, yes, you're right. Back to figuring out why the onload doesn't fire.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #10)

Ah, yes, you're right. Back to figuring out why the onload doesn't fire.

Scratch that. It was just a dumb mistake I made here - It seems the only problem is that window.opener is null. I'll try to work around that.

So, with test_uir I tried to get around the missing opener with the same trick Anne suggested for the cross-origin-opener tests - instead of postMessage to the opener, you embed an iframe of the same origin as the opener, and postMessage to that, and the iframe sends it back to the opener via a broadcast channel.

Here is my attempt: https://pastebin.com/WSZECGJs
The problem with this test is that one of the windows is http, the other https... and the https one has upgrade-insecure-requests set. Unfortunatelly, mochi.test:8888 can't really be upgraded to https 🙁

I have no idea why toolkit/components/extensions/test/mochitest/test_ext_webrequest_filter.html fails. I think we should fork a new bug for that one.

Tom, how should we proceed here? Are there more tests you wanted me to look at? I trust all the browser/base/content/test/siteIdentity/ tests now pass?

(In reply to Valentin Gosu [:valentin] (he/him) from comment #12)

So, with test_uir I tried to get around the missing opener with the same trick Anne suggested for the cross-origin-opener tests - instead of postMessage to the opener, you embed an iframe of the same origin as the opener, and postMessage to that, and the iframe sends it back to the opener via a broadcast channel.

Here is my attempt: https://pastebin.com/WSZECGJs
The problem with this test is that one of the windows is http, the other https... and the https one has upgrade-insecure-requests set. Unfortunatelly, mochi.test:8888 can't really be upgraded to https 🙁

I have no idea why toolkit/components/extensions/test/mochitest/test_ext_webrequest_filter.html fails. I think we should fork a new bug for that one.

I will file another bug for that. Thanks for looking into that!

Ah, I forgot to paste the try result here, sorry about that!
try: https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=278792001&revision=7389149789863e86855ddbad42bb887fa05730bf

I trust all the browser/base/content/test/siteIdentity/ tests now pass?

Not all the browser/base/content/test/siteIdentity/ tests pass:
TEST-UNEXPECTED-PASS | browser/base/content/test/siteIdentity/browser_bug1045809.js | We expect at least one assertion to fail because this test file is marked as fail-if in the manifest. -
TEST-UNEXPECTED-PASS | browser/base/content/test/siteIdentity/browser_mixedContentFramesOnHttp.js | We expect at least one assertion to fail because this test file is marked as fail-if in the manifest. -

I skimmed the content of the test browser_bug1045809.js. It opens a tab in "https://example.com" and the tab is embedded with an iframe in "http://test1.example.com". The test fails while the Fission is enabled so I assume the functionality of "mixedContent" seems not working while an iframe and its parent window are in the different process. However, it unexpectedly pass after I added --setpref browser.tabs.remote.useCrossOriginOpenerPolicy=true. Thus, I suspect maybe enabling the pref for COOP causes these two windows (parent window and iframe) to run in the same process?

Tom, how should we proceed here? Are there more tests you wanted me to look at?

Maybe we could discuss this in today's meeting.

I thought maybe there is an issue on our code so that these tests failed because of different origins unexpectedly runs in the same process in the Fission mode. Maybe I am wrong since it sounds like there are some issues with our testing framework based on your comment?

Timed out tests I collect:
TEST-UNEXPECTED-TIMEOUT | /upgrade-insecure-requests/link-upgrade.sub.https.html | ./link-upgrade/basic-link-upgrade.sub.html - Test timed out
TEST-UNEXPECTED-TIMEOUT | /worklets/animation-worklet-service-worker-interception.https.html | addModule() on a controlled document should be intercepted by a service worker. - Test timed out
TEST-UNEXPECTED-TIMEOUT | /service-workers/service-worker/about-blank-replacement.https.html | Popup initial about:blank is controlled, exposed to clients.matchAll(), and matches final Client. - Test timed out
TEST-UNEXPECTED-FAIL | dom/security/test/csp/test_uir_top_nav.html | Test timed out.
TEST-UNEXPECTED-FAIL | dom/security/test/csp/test_uir_windowwatcher.html | Test timed out.
TEST-UNEXPECTED-FAIL | dom/serviceworkers/test/test_fetch_event.html | Test timed out.
TEST-UNEXPECTED-FAIL | toolkit/components/extensions/test/mochitest/test_ext_webrequest_filter.html | Test timed out.
TEST-UNEXPECTED-FAIL | dom/security/test/csp/test_upgrade_insecure_navigation.html | Test timed out.
TEST-UNEXPECTED-FAIL | dom/base/test/chrome/test_chromeOuterWindowID.xhtml | Test timed out.
TEST-UNEXPECTED-FAIL | layout/base/tests/chrome/test_chrome_over_plugin.xhtml | Test timed out.

(In reply to Tom Tung [:tt, :ttung] from comment #13)

Tom, how should we proceed here? Are there more tests you wanted me to look at?

Maybe we could discuss this in today's meeting.

There seem to be multiple causes, we probably need to look into them one by one.

I will create a document for all these tests and somehow make them into different groups by the causes/signatures if it's possible. And then, hopefully, we can figure out how to deal with them.

(In reply to Tom Tung [:tt, :ttung] from comment #14)

I will create a document for all these tests and somehow make them into different groups by the causes/signatures if it's possible. And then, hopefully, we can figure out how to deal with them.

Doc (some works are still needed for the doc): https://docs.google.com/document/d/1gX-p0tx1aBGPD23HAWbXahuTECSRp3PWWnzRrjnMHKo/edit?usp=sharing

This code: https://searchfox.org/mozilla-central/rev/8bc24752246aeac8a9aed566cf1caccf88d97d11/netwerk/ipc/DocumentLoadListener.cpp#812

Is reading nsHttpChannel::mHasCrossOriginOpenerPolicyMismatch uninitialized, and getting true mostly.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=24031e7fba200f653569e4a864a80a1a9be58fad

Getting closer!

• Initializes mHasCrossOriginOpenerPolicyMismatch = 0
• Moves ProcessCrossOriginEmbedderPolicyHeader, ProcessCrossOriginResourcePolicyHeader and ComputeCrossOriginOpenerPolicyMismatch higher in the method, so we call them even when the channel gets cancelled for other reasons.

I see browser_new_web_tab_in_file_process_pref.js and browser_httpResponseProcessSelection.js failing, both of those tests use browser.tabs.remote.useHTTPResponseSelection=false to try to disable the process selection code. This is superceeded by the COOP pref though (which requires process selection), so testing the disabled configuration isn't working.

pbone is fixing those tests in bug 1592894 (to use the document channel pref), so these failures should go away this week.

https://hg.mozilla.org/mozilla-central/rev/7cc0c9dc6f3f