This patch doesn't change behavior; it's just collapsing logic from
nsPrintJob's Initialize method (which is now de-facto infallible) into the
constructor.
I'm also removing the "Methods needed by the DocViewer" header-comment since
it's clearly innacurate at this point. It's only surrounding this constructor
and GetSeqFrameAndCountSheets, which is silly since nsDocumentViewer uses more
of our API than that.
(I also placed TODO(dholbert) comments for a few things that looked odd, to
follow up on later. In particular, I noticed that nsDocumentViewer holds a
dedicated stack-owned RefPtr reference to nsPrintJob after creating it, which
superficially looks unnecessary. I don't want to risk changing behvior or
introducing a crash by removing that reference in this refactoring patch, so
I'm leaving that as-is and simply flagging it as suspicious.)
Depends on D150194
Differential Revision: https://phabricator.services.mozilla.com/D150195
This patch doesn't change behavior. It just changes to c++ reference types and
code-comments to indicate where we know that pointers have been null-checked
(and removes some null-checks that now become trivially-unnecessary).
I've added code-comments to justify why we know these args are non-null.
Generally, `nsPrintObject::Init`'s args are null-checked by the caller, except
in one case (in `nsPrintJob::DoCommonPrint`) where the Document* pointer in
question was _not_ directly null-checked by the caller. But fortunately, it is
null-checked earlier, higher up in the call-stack. So, this patch simply
propagates the C++ reference type-conversion up to that point for additional
clarity.
Differential Revision: https://phabricator.services.mozilla.com/D150078
Since bug 1659432 landed, we no longer keep the nsPrintJob around across print
settings changes, only replacing the nsPrintData. Now that we throw away
everything on a settings change it doesn't make sense to have code that was
written for juggling nsPrintData objects. That code was just making things
difficult to understand.
Differential Revision: https://phabricator.services.mozilla.com/D146718
The comments and structure of this code no longer made much sense after the
last 20 years of churn, including those made in bug 1659432 and bug 1552785.
Differential Revision: https://phabricator.services.mozilla.com/D146717
The comments and structure of this code no longer made much sense after the
last 20 years of churn, including those made in bug 1659432 and bug 1552785.
Differential Revision: https://phabricator.services.mozilla.com/D146717
Long ago we used to play switcheroo with PresShells in order to print a
document, but for over a decade we've been cloning the document that is
to be printed (bug 487667). Since then we've had no need for this method.
Differential Revision: https://phabricator.services.mozilla.com/D146545
Given how nsIPrintSettings is passed around, stored and copied all over the
place, it's very hard to reason about where and when a RemotePrintJobChild is
needed or valid. This patch avoids all that by explicitly passing a
RemotePrintJobChild when it's needed.
Another reason to make this change is because RemotePrintJobChild really does
not belong on nsIPrintSettings. That interface is supposed to represent a
collection of settings for laying out the document that is to be printed.
Differential Revision: https://phabricator.services.mozilla.com/D146380
When we do the initial reflow, we remove nodes from the document if
we're printing the selection. If these operations cause one iframe to be
removed, for example, then we may get hit with an nsIWebProgress
notification synchronously, which may cause us to go through
MaybeResumePrintAfterResourcesLoaded too early (and thus twice), which
messes up our state.
The ideal solution would be to add us as a listener a bit later, but we
can't because we need to know whether we did load anything during the
initial reflow.
So instead of that, just avoid resuming print while we're doing the
reflow. We'll call MaybeResumePrintAfterResourcesLoaded a few lines
below.
Differential Revision: https://phabricator.services.mozilla.com/D94586
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
This is backed by an existing nsPageSequenceFrame API, which this patch also
renames to use the word "Raw" for consistency across the full callstack.
Differential Revision: https://phabricator.services.mozilla.com/D87886
This code was there to prevent stuff like bug 424377, but nowadays clone
documents are data documents to begin with, so they can't load scripts.
Differential Revision: https://phabricator.services.mozilla.com/D86948
This also refactors the selection printing code, so that as we build the tree we
record which nsPrintObject should be used if printing a Selection is chosen.
Differential Revision: https://phabricator.services.mozilla.com/D85600
This also refactors the selection printing code, so that as we build the tree we
record which nsPrintObject should be used if printing a Selection is chosen.
Differential Revision: https://phabricator.services.mozilla.com/D85600
Otherwise my test fails intermittently on CI. We need to block on all
the load blockers because stuff like responsive images doesn't fire the
load directly but they do that as a micro task (blocking the load
event).
Differential Revision: https://phabricator.services.mozilla.com/D81989
Otherwise my test fails intermittently on CI. We need to block on all
the load blockers because stuff like responsive images doesn't fire the
load directly but they do that as a micro task (blocking the load
event).
Differential Revision: https://phabricator.services.mozilla.com/D81989
I had needed this before to export that header, and it's no longer
needed, but it seems useful anyways.
Depends on D81989
Differential Revision: https://phabricator.services.mozilla.com/D84252
This is going to be useful for the new print preview UI, which is in a
doorhanger and thus much more likely to be less than the page size.
We (ab)use the existing print preview scaling mechanism. We only need it
after reflowing all pages, so this works.
This whole scaling mechanism is all-in-all not amazing, but the patch is
less gross than I initially thought. It's nice, actually.
We could put the new behavior behind a pref trivially, if that's wanted,
but I honestly thing this behavior is better even without the doorhanger
ui.
Differential Revision: https://phabricator.services.mozilla.com/D83309
