The background we have on why this exists is in the code comments of the code
that's being removed, and in:
https://bugzilla.mozilla.org/show_bug.cgi?id=193001#c91
It seems very unlikely that this code is necessary. It's run for silent
printing when the new UI is enabled and E10s is disabled. If it was really
necessary it seems likely we'd have seen breakage in our much more common use
cases.
Differential Revision: https://phabricator.services.mozilla.com/D134936
The background we have on why this exists is in the code comments of the code
that's being removed, and in:
https://bugzilla.mozilla.org/show_bug.cgi?id=193001#c91
It seems very unlikely that this code is necessary. It's run for silent
printing when the new UI is enabled and E10s is disabled. If it was really
necessary it seems likely we'd have seen breakage in our much more common use
cases.
Differential Revision: https://phabricator.services.mozilla.com/D134936
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
When a page-size that is not auto or square exists the print preview will use
the orientation of this page-size when doing initial reflow. The frontend
applies the orientation to the print settings without updating settings and
causing a second reflow, and the orientation selector is hidden.
Differential Revision: https://phabricator.services.mozilla.com/D124976
This adds an optional paper orientation to PrintPreviewResultInfo populates it
from the CSS page size when finishing print preview. The value is then placed
in the PrintPreviewSuccessInfo to be sent to the frontend.
Differential Revision: https://phabricator.services.mozilla.com/D124248
It's unclear how this can happen (the caller also null-checks, but then
again it also reconstructs a bunch of stuff, so...).
Differential Revision: https://phabricator.services.mozilla.com/D113815
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
This patch does three things, all centered around these new APIs:
(1) Add the APIs themselves -- some nsIPrintSettings methods to reason about
the sheet-orientation being potentially flipped to accomodate 2 and 6
pages-per-sheet.
(2) Use these new APIs, where appropriate, in places where we previously used
the page-orientation to set up the platform-native print-settings objects and
print-target. Now, we'll use the *sheet* orientation instead of the page
orientation, to be sure we produce the appropriately-oriented platform-native
surfaces. Also, for symmetry, this patch adds similar logic to the reverse
codepaths, where we update an existing nsIPrintSettings object based on a
platform-native print-settings object.
(3) Update nsPrintJob's code that informs nsPresContext about the page-size.
This patch makes sure that this code uses the *page* size, rather than the
*sheet* size, in cases where they differ. (The code that consumes this
nsPresContext::GetPageSize API, e.g. our CSS media-query code, really does want
the page size, not the sheet size.)
Differential Revision: https://phabricator.services.mozilla.com/D100372
... which is an array of pairs of ranges, and use it instead of the
existing printRange / startPage / endPage settings.
Differential Revision: https://phabricator.services.mozilla.com/D96093
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
Recursive the things all :^)
The fix to the "corresponding node" bits in Document.cpp should be
pretty straight-forward. The fix in nsPrintJob is a bit more subtle:
The way printing selection works is literally "select everything else,
then call Selection.deleteFromDocument on that". We need to do the same
with shadow DOM, which involves skipping over shadow trees, and dealing
with selecting bits in ancestor trees as needed.
Note that for multi-range-selection case this technically relies on the
order of the ranges being shadow-tree-inclusive. We don't support
multi-range selection in shadow dom well, afaict, but I've added a
comment to the code to that effect.
Differential Revision: https://phabricator.services.mozilla.com/D93357
Otherwise we end up creating an in-process docshell and an initial,
non-static subdocument. This usually won't cause badness, but is wrong
and _can_ cause badness when printing selection etc.
The assertion I added is hit on existing tests and would've caught this.
Also fix another violation by grabbing the original docshell to clone
from before actually performing the clone, which could be null (and we'd
leave an initial document there). That would cause failures in
layout/printing/crashtests/1662259.html.
Differential Revision: https://phabricator.services.mozilla.com/D93279
This patch does the following things:
(1) It removes the legacy page-range-handling function
"DetermineWhetherToPrintPage()", and it now will always print every
PrintedSheetFrame.
(2) It activates PrintedSheetFrame's page-range handling function so that it
can take over responsibility for skipping pages during print operations.
(3) It adjusts the nsPrintJob code that kicks off individual asynchronous
"print the next page" operations (which is now really "print the next
PrintedSheetFrame). This nsPrintJob code used to have page-range-related
handling interwoven into it, and that handling isn't necessary anymore now that
we're handling page-skipping up front at layout time.
(4) It replaces the mPageNum member-var (which tracks which page we're about to
print or are currently printing) with mCurrentSheetIdx, which is now a 0-based
index into the list of PrintedSheetFrame instances.
(5) It removes nsPrintData:mNumPagesPrinted, which was only used for
progress-bar-completion updates & which basically tracked the same information
that I'm tracking in the new mCurrentSheetIdx variable.
There's some additional cleanup that we should do after this lands (e.g. some
s/page/sheet/ renamings) but I'm holding off on that for now, to keep this
patch relatively targeted.
Differential Revision: https://phabricator.services.mozilla.com/D92660
This was the last flag that the PrintOptions bitfield was tracking.
So, this patch is effectively converting that bitfield (and its alias
"PrintOptionsBits") into a new, simpler boolean field named
"isPrintSelectionRBEnabled".
Differential Revision: https://phabricator.services.mozilla.com/D92542
