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
This works, though probably we want to do some follow-up tweaks, like
the adding of the onload blocker and so on, so that we can avoid the
UpdateDimensions hack.
We may also want a PrintObject in the nsPrintJob tree, perhaps...
Differential Revision: https://phabricator.services.mozilla.com/D90310
This broke in bug 1636728 because we started setting the bit in the
cloned docshell rather than the original one.
Behavior in other browsers seems to be a bit all over the place, but for
now keeping our behavior during window.print() seems sane.
Differential Revision: https://phabricator.services.mozilla.com/D90456
I don't see any reason why this shouldn't work off-hand, there's no
gtk globals or such that fundamentally avoid sharing settings.
The PSPrinters stuff is gone so it's not needed to mess up with PS/CUPS
names.
The last used printer name stuff is now just a pref read, so there
shouldn't be sandbox violation shenanigans...
There are some restrictions on what can be set or what not (like, if you
set the paper name that may also override the paper size).
But these are problems that we have when restoring from prefs already,
so there's no reason we shouldn't do this, afaict.
Differential Revision: https://phabricator.services.mozilla.com/D90418
Though there is no automated test for this change, I think the test cases in the
previous commit well cover the original issue (bug 468568) that downloadable
fonts are not rendered in printing.
Depends on D89095
Differential Revision: https://phabricator.services.mozilla.com/D89096
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
