1776169 - Split cloning and layout for cross-origin iframes into two separate steps

Status: NEW

(Core :: Printing: Setup, defect, P3)

Description

[Jonathan Watt [:jwatt]]

In nsGlobalWindowOuter::Print we call GetDefaultPrintSettingsForPrinting if aPrintSettings is null, which happens when this function is invoked by a window.print() call.

The question is, why do we even need this settings object at this point, given that in the window.print() case we only do the static clone when invoked by window.print(), and we avoid doing any pagination/layout until later (after a round-trip to the parent process) when we have a valid nsIPrintSettings object to do it with.

It turns out that, surprisingly, the thing we're doing with the settings object is passing it to the CreateStaticClone call. You would hope that a print settings object would be completely unnecessary for the clone, but it turns out that, since D119103, we've been calling UpdateRemotePrintSettings in BrowserChild::RecvCloneDocumentTreeIntoSelf. In other words, unfortunately there's not currently a strong separation between cloning and the subsequent layout for window.print() when it comes to any cross-origin iframes (as there is for those two operations in the originating nsGlobalWindowOuter::Print call, as described above).

Really we should change the code to have cloning and layout done in two distinct steps for cross-origin iframes. In that case CreateStaticClone wouldn't need an nsIPrintSettings object to be passed, and we wouldn't need the GetDefaultPrintSettingsForPrinting call mentioned above.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:emilio, could you have a look please?

For more information, please visit auto_nag documentation.