User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

1. Navigate to https://www.instrupix.com/wprm_print/recipe/5935
2. Click "Print"

Actual results:

The tab crashed and displayed a crash notification

Expected results:

The print preview dialogue should have displayed

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

kyoji1, thanks for reporting!

I can't reproduce the crash on the latest nightly on Windows 10.

Can you please provide more detailed information? I suppose you are using nightly builds, what is the build date? And also can you please paste the crash id? You can find it in about:crashes.

Thanks!

Presumably this should be "[print2020_v81] [old-ui-]"

Hiroyuki,

I am using Nightly builds, yes. I just tried on the latest build (82.01a 2020-08-29) and the new print preview UI no longer crashes, but fails to generate a print preview. Please see below. Thank you!

https://1drv.ms/u/s!AvnKpfZK5_w0jZ4SVouSboYoaCuXag?e=5edUcT

Thank you kyoji1 for quick testing.

One more thing I want to make clear, are you opening the link in a container tab? Actually I couldn't reproduce the issue you saw, but I happened to open the link in a container tab and then I can reproduce the issue.

Though I am not sure attaching this browser mochitest here is the right thing to do, this is an automated to test (that I believe testing this bug).

Thanks for filing this kioji! I had seen that URL in our crash reports, but couldn't manage to make it crash and reproduce because I didn't try with container tabs. And thanks for the diagnostic hiro!

So the root cause seems similar to bug 1661984. We spawn the print preview document just fine, but we bail out when swapping it into the preview tab here. Unfortunately, the front-end just eats the error, and we proceed to remove the browser without having swapped its guts, which means that when printPreview is called on the tab we think that the tab is discarded already, and that caused us to crash (and causes us to bail out now).

The root cause of course is that the origin attributes were not being copied properly. Will dig into it.

This was a pre-existing bug that my patch uncovered it.

Hey Hiroyuki,

I have the container tabs extension installed, but was not opening the site in a container tab. I have tried the same process on a different computer running Windows 10, Nightly build 2020-08-31 and the print preview appears and generates the preview as expected.

I was able to re-produce the bug by opening the site in a container tab as you reported.

Thanks for your hard work everyone!

Thank you, kyoji1! That's interesting. The issue Emilio and I saw is caused by userContextId which means it's container tab related thing. Based on comment 7, there may be other possibilities causes the hang, if we fail in swapFrameLoaders, we can't tell the failure unfortunately now.

Anyways, let's see whether the change in comment 10 fixes the issue on your end. If it didn't unfortunately, I will ask you to open a new bug. Thank you!

https://hg.mozilla.org/mozilla-central/rev/5405f08263fb

Hey kyoji1, could you please check again whether the print preview still gets stuck on the latest nightly on your environment? (Please make sure
the document is not opened in a container tab). If it still gets stuck, please open a new bug and CC me!

Note that the buildid: 20200831215215 includes the fix in comment 10, you can check the buildid in about:support. Thanks!

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

Hey kyoji1, could you please check again whether the print preview still gets stuck on the latest nightly on your environment? (Please make sure
the document is not opened in a container tab). If it still gets stuck, please open a new bug and CC me!

Note that the buildid: 20200831215215 includes the fix in comment 10, you can check the buildid in about:support. Thanks!

Hey Hiroyuki,

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.

Thanks again to you and the amazing FF team :)

Thank you kyoji1 for your quick response.

I filed bug 1662325 for the issue you are still seeing. If you find something which might be a cause of the stuck, it would be really helpful (that said, I don't want you to force it).

Anyways, thanks for your cooperation!

Comment on attachment 9172987 [details]
Bug 1661867 - Create the print preview browser with the right userContextId. r=jwatt

Beta/Release Uplift Approval Request

• User impact if declined: Printing project
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): crash fix
• String changes made/needed:

Comment on attachment 9172987 [details]
Bug 1661867 - Create the print preview browser with the right userContextId. r=jwatt

Approved for 81.0b6.

https://hg.mozilla.org/releases/mozilla-beta/rev/87c1dc1418d9

Reproduced this issue using Firefox 82.0a1 (BuildId:20200828153126).

This issue is verified fixed using Firefox 82.0a1 (BuildId:20200907094115) and Firefox 81.0b7 (by manually enabling the containers via privacy.userContext.enabled pref) on Windows 10 64bit, macOS 10.14 & Ubuntu 18.04 64bit.