Requires pref fission.autostart=true and --enable-fuzzing builds for access to window.printPreview() from js.

I do not have a reliable reduced test case at the moment but hopefully I will be able to get a Pernosco session.

Assertion failure: aPendingSwitchId (We always have a PendingSwitchId, except for print-preview loads, which will never perform a process-switch to being in-process with their embedder), at src/docshell/base/CanonicalBrowsingContext.cpp:1311

#0 0x7f47426b5912 in mozilla::dom::CanonicalBrowsingContext::ChangeRemoteness(nsTSubstring<char> const&, unsigned long, bool, unsigned long) src/docshell/base/CanonicalBrowsingContext.cpp:1307:5
#1 0x7f473ebc58c5 in mozilla::dom::ContentParent::RecvCloneDocumentTreeInto(mozilla::dom::MaybeDiscarded<mozilla::dom::BrowsingContext> const&, mozilla::dom::MaybeDiscarded<mozilla::dom::BrowsingContext> const&) src/dom/ipc/ContentParent.cpp:3668:9
#2 0x7f4738a3c09a in mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PContentParent.cpp:6728:57
#3 0x7f473874999e in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) src/ipc/glue/MessageChannel.cpp:2150:25
#4 0x7f4738745954 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) src/ipc/glue/MessageChannel.cpp:2074:9
#5 0x7f4738747758 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) src/ipc/glue/MessageChannel.cpp:1922:3
#6 0x7f4738748228 in mozilla::ipc::MessageChannel::MessageTask::Run() src/ipc/glue/MessageChannel.cpp:1953:13
#7 0x7f47374499e9 in mozilla::RunnableTask::Run() src/xpcom/threads/TaskController.cpp:450:16
#8 0x7f47374464a7 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) src/xpcom/threads/TaskController.cpp:720:26
#9 0x7f47374443e7 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) src/xpcom/threads/TaskController.cpp:579:15
#10 0x7f473744483d in mozilla::TaskController::ProcessPendingMTTask(bool) src/xpcom/threads/TaskController.cpp:373:36
#11 0x7f47374514d1 in operator() src/xpcom/threads/TaskController.cpp:120:37
#12 0x7f47374514d1 in mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_3>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:577:5
#13 0x7f4737471f0b in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1197:14
#14 0x7f473747cc0c in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:513:10
#15 0x7f473875254f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:87:21
#16 0x7f4738654671 in RunInternal src/ipc/chromium/src/base/message_loop.cc:334:10
#17 0x7f4738654671 in RunHandler src/ipc/chromium/src/base/message_loop.cc:327:3
#18 0x7f4738654671 in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:309:3
#19 0x7f473f467167 in nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:137:27
#20 0x7f4742f7b6fa in nsAppStartup::Run() src/toolkit/components/startup/nsAppStartup.cpp:270:30
#21 0x7f474319fd4f in XREMain::XRE_mainRun() src/toolkit/xre/nsAppRunner.cpp:5091:22
#22 0x7f47431a210b in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) src/toolkit/xre/nsAppRunner.cpp:5283:8
#23 0x7f47431a2a13 in XRE_main(int, char**, mozilla::BootstrapConfig const&) src/toolkit/xre/nsAppRunner.cpp:5339:21
#24 0x55af5b1a6ff5 in do_main src/browser/app/nsBrowserApp.cpp:218:22
#25 0x55af5b1a6ff5 in main src/browser/app/nsBrowserApp.cpp:336:16

A Pernosco session is available here: https://pernos.co/debug/Ek9S9eVzbLiHbocbygeIHA/index.html

kmag says this is a print or print-preview load.

I haven't had a ton of time to properly look into the pernosco trace, but I think this is caused by a remote subframe racing to switch to be in-process while printPreview is trying to perform a remote static clone of it. When the static clone starts, the content process thinks the subframe is remote, but when the message arrives in the parent, the parent thinks it is local instead. We then hit this assertion, as we're attempting to do a process-switch-to-local for printPreview, which isn't implemented.

ni? :emilio who originally wrote a bunch of this code.

The guess in comment 3 is basically right, here's the relevant bits that
happen in that trace in order:

[content] nsFrameLoaderOwner::ChangeRemotenessCommon:
frame becomes remote for the content process.
[parent] WindowGlobalParent::SendMakeFrameLocal (mIsDocumentLoad=true)
[content] ContentChild::SendCloneDocumentTreeInto
[parent] ContentParent::RecvCloneDocumentTreeInto
[content] WindowGlobalChild::RecvMakeFrameLocal

So basically the source frame we're cloning is mid-switch-to-local:
local already from the parent process POV, but still remote for the
child.

I think ignoring the clone in this case is fine (which will make the
print iframe just about:blank).

I've decided it to handle it in ChangeRemoteness but I could also handle
it in RecvCloneDocumentTreeInto with a check like

if (cp->GetRemoteType() == GetRemoteType())

or such I think. Let me know if you'd prefer that.

https://hg.mozilla.org/mozilla-central/rev/2ca4e50483b9