1. https://aka.ms/wslstore

This opens the Microsoft Store for some reason...

2. Assert Windows Nightly

Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Suspend), at z:/build/build/src/uriloader/exthandler/nsExternalProtocolHandler.cpp:343
#01: nsresult mozilla::detail::RunnableFunction<`lambda at z:/build/build/src/uriloader/exthandler/nsExternalProtocolHandler.cpp:179:44'>::Run() [xpcom/threads/nsThreadUtils.h:564]
#02: nsThread::ProcessNextEvent(bool,bool *) [xpcom/threads/nsThread.cpp:1226]
#03: NS_ProcessNextEvent(nsIThread *,bool) [xpcom/threads/nsThreadUtils.cpp:486]
#04: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate *) [ipc/glue/MessagePump.cpp:88]
#05: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:309]
#06: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:291]
#07: nsBaseAppShell::Run() [widget/nsBaseAppShell.cpp:139]
#08: nsAppShell::Run() [widget/windows/nsAppShell.cpp:406]
#09: nsAppStartup::Run() [toolkit/components/startup/nsAppStartup.cpp:277]
#10: XREMain::XRE_mainRun() [toolkit/xre/nsAppRunner.cpp:4586]

Can you reproduce on a debug build with a better stack? We need to know what is calling channel->Suspend(), I expect, and the previous frame is this runnable which doesn't do that itself - it'll be the listener's onStart/onStopRequest that's calling Suspend...

We open the windows store because the URL redirects to ms-windows-store://collection/?CollectionId=LinuxDistros or something like that, and the windows store is the registered protocol handler for protocols like that.

I didn't try to reproduce but this log is from the original run and contains the full crash report. Looks like mozilla::net::DocumentChannelParent::OnStartRequest ?

 0  xul.dll!nsExtProtocolChannel::Suspend() [nsExternalProtocolHandler.cpp:caf55914ccddba34d462a1206530d7868b6c4992 : 343 + 0x0]
 1  xul.dll!mozilla::net::DocumentChannelParent::OnStartRequest(nsIRequest *) [DocumentChannelParent.cpp:caf55914ccddba34d462a1206530d7868b6c4992 : 614 + 0xa]
 2  xul.dll!nsresult mozilla::detail::RunnableFunction<`lambda at z:/build/build/src/uriloader/exthandler/nsExternalProtocolHandler.cpp:179:44'>::Run() [nsThreadUtils.h:caf55914ccddba34d462a1206530d7868b6c4992 : 564 + 0x13]

The log has the full report and std{out,err} from the run.

This is from https://searchfox.org/mozilla-central/rev/42c2ecdc429115c32e6bcb78bf087a228a051044/netwerk/ipc/DocumentLoadListener.cpp#635-636 ; per https://searchfox.org/mozilla-central/rev/42c2ecdc429115c32e6bcb78bf087a228a051044/netwerk/ipc/DocumentLoadListener.cpp#681-686 this is somewhat known. Matt, what's the plan for this code and/or can we avoid tripping this assert somehow? It doesn't look like there's a specific interface we can check for, but perhaps we can check if the scheme in mUrl is externally handled or detect this case some other way... Or we could just remove the asserts? Looks like they've been there since mscott added them in 2001 so not sure whether it makes sense to keep them.

Bug 1598516 has a fix for this! I'll try land early next week when the soft freeze is over.

Bugbug thinks this bug is a regression, but please revert this change in case of error.