When we print without print preview, we create a static clone and a new docshell. However, we set the docshell's tree owner to be the same as the original docshell's owner. This really gets is the way of getting printing working for Fission. It would be safer and more consistent if we always had a tab to clone into. In the case of a direct print this tab should obviously be hidden.

Tracking for Fission Nightly M6b because this bug blocks some other Fission printing work.

Hi Neil: Is this something you'd be able to help us out with implementing?

Now that we triage by severity, setting priority to P1 to reflect backlog prioritization on this bug as either in-progress, or planned development in the near term. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

By 'tab', do you mean a hidden browser element? Or do you mean you want to open print preview in a regular tab?

I can help in some way I think, but will need more detail about what is needed here.

When the user opens print preview, PrintUtils.printPreview is called and is passed the PrintPreviewListener from browser.js. That object provides methods to create a print preview tab, simplified doc tab, and simplified doc print preview tab. The code in PrintUtils._enterPrintPreview then calls one of those methods (such as getPrintPreviewBrowser) which will create a new tab, and then sends that new tab's message manager a message with the window ID of the original window from which the print is to be made. On the content side PrintingChild.enterPrintPreview invokes nsDocumentViewer::PrintPreview on the new tab's nsDocumentViewer, passing the window of the original document as an argument so that the platform code can clone the original document into the new tab.

PrintUtils.print on the other hand does none of this new tab stuff. It simply invokes nsDocumentViewer::Print on the nsDocumentViewer of the original document that is to be printed.

From the point of view of the platform code, we simply want direct printing via PrintUtils.print to invoke nsDocumentViewer::Print on the viewer of a new window that we can clone the original document into. It doesn't necessarily need to be a new tab (so long as the window lives until the print is done).

needinfo'ing Nika in case she has anything to add to the above.

Theoretically, the environment needed for printing wouldn't require much more than a hidden <browser> element to clone into, potentially within a windowless browser. I don't think there are any dependencies on frontend code during the static clone and printing process which would require the tabbrowser to participate. However, it could be nice to use a "real" tabbrowser tab for printing, in order to be as similar as possible to the environment used for print-preview and to avoid potential behaviour issues which wouldn't get caught during testing.

Once the new hidden <browser> element is created, whether in a tab or within a windowless browser, we'll probably want to have frontend hand off to platform code immediately, before sending a message into the content process, so that it can simultaneously clone all of the remote subdocument trees from the original document. The platform code could presumably either fire an event when the tab is ready to be cleaned up, or return a promise which is resolved then.

If we decide to go the windowless browser approach, I might lean towards creating and using this windowless browser directly from within platform code, rather than frontend, in order to make it more portable, and make configuring the load context easier.

we need printing for fission fixed in M6b

Is it fair to say this is moot once we ship the new print preview UI? At that point, there will be no way to print without print preview.

No, that's not the case. (We still want the final print to be in a hidden tab. And there's still the pref print.always_print_silent and other circumstances such as extensions setting nsIPrintSettings.printSilent = true where we need somewhere other than the new UI to create the static clone.) However, the remaining parts to fix this bug should become fairly trivial after emilio lands his patch for bug 1636728.

Sean said fission printing work will most probably not be ready in time for nightly experiment and we shouldn't block on it. It is expected to be fixed in a couple of weeks following the experiment launch.

Emilio actually fixed this in bug 1636728.