nsPageSequenceFrame does a thing where it grows its desired size to fit the
AvailableISize and ComputedBSize (under the assumption that those are the
actual dimensions of our scrollport, which it wants to make maximal use of).
This behavior causes trouble when it's reflowed under the privileged
'sizeToContent' JS API. That API makes us reflow with nscoord_MAX as the
viewport's ComputedBSize(), and this nscoord_MAX value gets passed down to be
the nsPageSequenceFrame's ComputedBSize as well. When we reach the code in
question, we dutifully grow the desired size to that bogus huge value, which is
clearly wrong.
This patch addresses this issue by simply declining to grow the desired size in
the scenario where ComputedBSize() is unconstrained. This leaves us with
reasonable values for our desired size (which are actually based on the
content, which makes it the right thing to do for the purpose of a
SizeToContent() call).
Differential Revision: https://phabricator.services.mozilla.com/D135762
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
Actually, there's not so much we can improve right now, in the sense
that:
* We need the ::-moz-page-content pseudo-element to be able to set
`display` on the page, since that's a style rule rather than a @page
rule. We could get away without it.
* Keeping the current code-path (slightly cleaned up) is less code, for
now at least. We can have a separate code-path or what not that
actually performs the @page rule selector-matching and what not if
needed when we get to named pages or other page selectors. Selectors
like :first should be pretty trivial to implement, actually.
We make some paged mode anon boxes non-inheriting anon boxes. This
allows us to share the styles and is generally nicer. They don't need to
inherit from anywhere.
We could remove the origin handling and don't look at UA rules or what
not, but it seems pretty harmless to do that.
We also fix the name of the pseudo-elements to match the capitalization.
Differential Revision: https://phabricator.services.mozilla.com/D104772
This code currently does a recursive tree-traversal to get a list of all canvas
elements that might be used for PDF.js content, so that we can invoke the
appropriate callbacks on them to let PDF.js prepare for printing.
In this patch, I'm adjusting the outermost level of that traversal to make it
aware of the fact that PrintedSheetFrames may now contain many skipped
nsPageFrames whose content we don't want to render.
Depends on D101941
Differential Revision: https://phabricator.services.mozilla.com/D101942
This patch doesn't change behavior; it just adds a static_cast to a
more-specific type that we know the variable has, and updates the signature and
callsites.
(The next patch will make use of the fact that we know this type.)
Differential Revision: https://phabricator.services.mozilla.com/D101941
This patch doesn't change behavior. It's just a simplification of the data
that we track for our different pages-per-sheet mode (with some minor
refactoring of the logic involved).
This is a necessary step towards implementing support for 2 and 6
pages-per-sheet (which are referenced in comments included in this patch,
and which will be implemented separately in bug 1669905)
Differential Revision: https://phabricator.services.mozilla.com/D99180
... 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
This renames kTimeFormatSeconds to kTimeFormatLong and kTimeFormatNoSeconds to
kTimeFormatShort. This is consistent with the naming used for date format
selectors.
Differential Revision: https://phabricator.services.mozilla.com/D93011
The idea here is that we reflow each page as if it were the only page on its
sheet, and then we transform it as-needed to put it in the right
"pages-per-sheet" cell, at paint time.
LIMITATION: Right now I haven't implemented the values "2" and "6", since those
will involve a bit of extra complexity to rotate the sheet to be orthogonal to
the page sizes (and to only do that if the page's aspect ratio merits it). That
will be covered in followup bug 1669905.
Differential Revision: https://phabricator.services.mozilla.com/D86800
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 code looked like it might work, but it seems to have only ever been backed
by per-printer about:config prefs. I believe we only ever exposed UI for this
feature on Linux, via the native GTK dialog; and even there, the UI doesn't
actually seem to have done anything -- it was never wired up to the actual
implementation of even/odd page-skipping.
Differential Revision: https://phabricator.services.mozilla.com/D92528
We were adding the unwriteable to the default margin. I was going to
consider not painting the headers / footers if they overlapped with the
content box of the page, but turns out our default configuration
overlaps slightly at the bottom, so I just punted on that.
Users can remove the headers / footers quite easily anyhow.
Differential Revision: https://phabricator.services.mozilla.com/D89794
Canvas only has one context, and that assumption is pretty baked into
the code, so having an API that pretends otherwise is silly.
Differential Revision: https://phabricator.services.mozilla.com/D88990
This patch shouldn't change behavior.
After this change, we'll be able to reason about the page range during reflow
(in a later patch in this series). The old place where we determine the
page-range information -- in nsPageSequenceFrame::StartPrint -- unfortunately
runs *after* reflow. So that was running too late for the information to be
useful when we're laying out pages on sheets.
Differential Revision: https://phabricator.services.mozilla.com/D88469
This patch shouldn't change behavior at all; it's just moving some member
variables to a new home on a helper-struct (and the struct's lifetime is the
same as the lifetime of the nsPageSequenceFrame where these member variables
lived, prior to this patch).
These members need to move so that PrintedSheetFrame can have access to them.
PrintedSheetFrame is now where pages are generated, and it will handle our
page-range-induced page skipping, as of a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D88468
Before this patch stack, nsPageSequenceFrame and every nsPageFrame each
individually tracked the number of pages.
As of the previous patch, we've coalesced the nsPageFrame variables into a
single variable that lives on nsSharedPageData. This patch here replaces
nsPageSequenceFrame's member-var with that nsSharedPageData variable, too.
Depends on D87696
Differential Revision: https://phabricator.services.mozilla.com/D87697
Note: Previously we were scaling based on the available ISize (and we were
ignoring the BSize for scaling purposes). Now we want to consider the BSize as
well, so the obvious next step would be to scale based on the available BSize -
but that doesn't work, because the available BSize is unconstrained here. (It's
unconstrained, even though we're fragmenting, because thankfully we don't
attempt to fragment the nsPageSequenceFrame itself -- we only fragment at a
level further down in the frame tree.)
So: this patch changes us to instead scale down based on the *computed* size
(rather than the available size), such that both dimensions fit. The computed
size here is the size of the scrollport; and, importantly, it has a finite
value in the block axis (unlike the *available* BSize which is unconstrained
here).
Note that the available ISize and the computed ISize are the same in this case
(they're both the ISize of the scrollport), so there's no behavior-change here
for the computation of the inline-axis-based scale factor.
Differential Revision: https://phabricator.services.mozilla.com/D87021
Note: Previously we were scaling based on the available ISize (and we were
ignoring the BSize for scaling purposes). Now we want to consider the BSize as
well, so the obvious next step would be to scale based on the available BSize -
but that doesn't work, because the available BSize is unconstrained here. (It's
unconstrained, even though we're fragmenting, because thankfully we don't
attempt to fragment the nsPageSequenceFrame itself -- we only fragment at a
level further down in the frame tree.)
So: this patch changes us to instead scale down based on the *computed* size
(rather than the available size), such that both dimensions fit. The computed
size here is the size of the scrollport; and, importantly, it has a finite
value in the block axis (unlike the *available* BSize which is unconstrained
here).
Note that the available ISize and the computed ISize are the same in this case
(they're both the ISize of the scrollport), so there's no behavior-change here
for the computation of the inline-axis-based scale factor.
Differential Revision: https://phabricator.services.mozilla.com/D87021
This patch:
- Creates an anon-box pseudo-style for PrintedSheetFrame, in part so that it
can co-opt the styles that we formerly gave to page-frames in ua.css, to draw
the sheet of paper and the shadow in Print Preview.
- Adjusts nsCSSFrameConstructor to create a PrintedSheetFrame as the parent of
nsPageFrame (inserting between it and its nsPageSequenceFrame container, in
the frame tree).
- Fleshes out out a simple BuildDisplayList() implementation for
PrintedSheetFrame (taking the responsibility for "paper"-drawing from
nsPageFrame).
- Fleshes out a simple Reflow implementation for PrintedSheetFrame, just
placing the child page (assuming there's only one for now) at the origin.
- Adjusts nsPageFrame and nsPageSequenceFrame to account for the fact that
there's another layer between them now.
Note that PrintedSheetFrame needs to implement AppendDirectlyOwnedAnonBoxes()
(just as nsSimplePageSequence and nsPageFrame do), since it owns anonymous
nsPageFrame instances. This implementation only needs to append the first
child, as explained in the code-comment and in
https://bugzilla.mozilla.org/show_bug.cgi?id=1374761#c9 (and of course, for
now, PrintedSheetFrame only has one child at a time anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D83457
For a given ::Reflow call, we have an expectation that the ReflowInput and
ReflowOutput should be "matching". In particular: we should use the
ReflowInput to initialize the ReflowOutput, and we should pass both of these to
the frame's Reflow method.
In current mozilla-central (prior to this patch), nsPageSequenceFrame violates
this expectation when it prepares to reflow its children, in the following
ways:
1) It passes in the wrong ReflowInput as an arg when constructing a
ReflowOutput struct for its children. (It passes *its own* ReflowInput arg,
rather than the ReflowInput for the child that it's about to reflow.)
2) It *reuses* that single ReflowOutput structure *for all of its children*,
which means that sizing information from one child will end up improperly
influencing later children by "leaking through".
This results in overflow areas that are artificially too large on nsPageFrames,
because ReflowOutput populates its overflow areas via "union()" operations. So
the improperly-reused ReflowOutput produces a strictly larger overflow area
on each subsequent page (even if the page doesn't actually have any overflow).
This patch fixes these problems by creating a new ReflowOutput for each child,
and initializing it with the correct ReflowInput instance.
Notably, this patch *is* a behavior-change (in the direction of correctness).
In particular, we won't have artificially-inflated overflow areas on later
nsPageFrame instances anymore, and so now some of our automated testcases
trigger assertion-failures that they were getting around before. These all
seem to be versions of https://bugzilla.mozilla.org/show_bug.cgi?id=1655630
which, "fortunately", is already reproducible (under certain paper sizes)
even in a build from current mozilla-central, without this here patch.
Differential Revision: https://phabricator.services.mozilla.com/D85098