From bug 1661867 comment 15

The problem still persisted for me, no container tab in use. I created a fresh profile for nightly on the latest build and the issue was not present.
It has to be something on my end with my default profile.

So I am pretty sure there is still something making the print preview stuck. We'd like to identify the reason.

Bump this to P1 if we can find a reproducible testcase. (CCing QA for awareness in case it pops up in testing.)

Bug 1653340 handles platform errors a lot more robustly so may help with the issue kyoji1 is encountering (it won't be used until bug 1660527 lands though). There is also scope for frontend code to do something wrong too of course, so it also may not.

Hi kyoji1, would you mind trying the latest nightly with your default profile again? Thanks!

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)

Hi kyoji1, would you mind trying the latest nightly with your default profile again? Thanks!

Hey Hiroyuki,

Unfortunately the issue still persists on Nightly 2020-09-04 using my default profile. Is there anything I can share with you that might help make this reproduceable?

I forgot to add to my previous comment that the print preview only hangs when the "Print" button is clicked. Bringing up the print preview manually (Ctrl + P) it generates as expected.

It might provide some helpful info if you don't mind following the following steps:

• Open Tools -> Web Developer -> Browser Console
• Click the trash can icon to clear any current messages
• Switch back to the page you want to print and try to print it
• Once the problem occurs, switch back to the Browser Console window
• Right click on one of the messages in the Browser Console to open the context menu
• From the context menu, select Export Visible Messages To -> File and save the file
• Attach the file to this bug

You could then repeat the above steps, but instead of selecting Browser Console in the first step, select Web Console.

Obviously the names of the above menu items will likely be different in your version of Firefox, but hopefully the above is clear enough to figure it out?

I think it is likely that the issue is probably in your preferences somewhere. Another step that would be helpful is if you could open the page about:support, click the Copy text to clipboard button, and then save that to file and attach it here. NOTE: please do check through the contents of this file first to make sure you're happy to attach it to this public bug. I don't think it should contain anything private, but all sorts of things are saved to preferences.

Removed Media section, removed specific video card model from Graphics section

(In reply to Jonathan Watt [:jwatt] from comment #7)

I think it is likely that the issue is probably in your preferences somewhere. Another step that would be helpful is if you could open the page about:support, click the Copy text to clipboard button, and then save that to file and attach it here. NOTE: please do check through the contents of this file first to make sure you're happy to attach it to this public bug. I don't think it should contain anything private, but all sorts of things are saved to preferences.

Hey Jonathan,

I've attached both files. I removed the Media category since it included a lot of specific hardware installed in my machine that I would rather not be public. I also removed my specific video card model from the Graphics section.

Hope either are helpful. There was no output in the regular developer web console.

Thank you kyoji! That's greatly helpful!
Now I could reproduce the hang!

(In reply to Hiroyuki Ikezoe (:hiro) from comment #11)

Thank you kyoji! That's greatly helpful!
Now I could reproduce the hang!

That's great news, glad it was helpful! How did you reproduce it?

(In reply to kyoji1 from comment #12)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #11)

Thank you kyoji! That's greatly helpful!
Now I could reproduce the hang!

That's great news, glad it was helpful! How did you reproduce it?

Setting privacy.firstparty.isolate to true in about:config and then open the document in question and push the print button there.

There are a few errors in the console, but it looks like this is the pertinent one at [1]:

can't access property "outerWindowId", sourceBrowsingContext.currentWindowGlobal is null print.js:460
_updatePrintPreview chrome://global/content/print.js:460
_updatePrintPreviewTask chrome://global/content/print.js:195
_runTask resource://gre/modules/DeferredTask.jsm:333
_timerCallback resource://gre/modules/DeferredTask.jsm:305
_timerCallback resource://gre/modules/DeferredTask.jsm:324
callback resource://gre/modules/DeferredTask.jsm:179
(Async: ChromeUtils::IdleDispatch handler)
_startIdleDispatch resource://gre/modules/DeferredTask.jsm:192
callback resource://gre/modules/DeferredTask.jsm:173

[1] https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/toolkit/components/printing/content/print.js#460

The situation is pretty much same as bug 1661867, we fail the origin attributes check in nsFrameLoader::SwapWithOtherRemoteLoader.

I've looked relevant code, currently we have no way to set either the origin attributes or the first party domain explicitly (e.g. with createBrowser etc.). We need a new method for that, IIUC.

Potentially simpler alternative: Just don't check first party domain in SwapWithOtherRemoteLoader.

https://hg.mozilla.org/mozilla-central/rev/c8b4b1b60733