The pref was enabled by default in bug 2002115 and shipped in Firefox 151. Since
it has been two releases, we can remove it to simplify the code path.
Differential Revision: https://phabricator.services.mozilla.com/D302349
Same implementation over two different compilation units advocate for
promotion to a method.
This also prevents conflicts in the generalization of unified build.
Differential Revision: https://phabricator.services.mozilla.com/D298968
Removed the Reflow Input in nsIFrame. Added includes for ReflowInput as
necessary in cpp files. Also Forward Declared nsLineLayout in 3 header
files.
Differential Revision: https://phabricator.services.mozilla.com/D298203
Moved ReflowInput::BreakType enumuration outside ReflowInput class to mozilla::BreakType, and refactored the functions using it to reflect the change.
Differential Revision: https://phabricator.services.mozilla.com/D298034
And remove unused includes of nsGkAtoms.h in the process. The few
dependencies have been moved to ServoStyleConstsInlines.h
The used command to remove the now unused dependency was:
git grep -l nsGkAtoms.h | while read line; do grep -v nsGkAtoms.h $line | grep -q -E '\<nsGkAtoms\>' || sed -i -e '/nsGkAtoms.h/d' $line ; done
Differential Revision: https://phabricator.services.mozilla.com/D292697
And remove unused includes of nsGkAtoms.h in the process. The few
dependencies have been moved to ServoStyleConstsInlines.h
The used command to remove the now unused dependency was:
git grep -l nsGkAtoms.h | while read line; do grep -v nsGkAtoms.h $line | grep -q -E '\<nsGkAtoms\>' || sed -i -e '/nsGkAtoms.h/d' $line ; done
Differential Revision: https://phabricator.services.mozilla.com/D292697
This extends the measuring reflow mechanism from multicol (Bug 1994346) to
printing scenarios. When absolutely positioned elements exist, we now perform
an initial measuring reflow with an unconstrained page height to compute
unfragmented positions, sizes, etc.
Each frame type (nsPageSequenceFrame, nsPageFrame, PrintedSheetFrame,
nsPageContentFrame) has their own logic to calculate the available size for its
child, and they do not derive the size from their own reflow input's available
size. To avoid substantial refactoring, this patch checks
`mIsInFragmentainerMeasuringReflow` and overrides the available block-size to
unconstrained when running a measuring reflow.
Differential Revision: https://phabricator.services.mozilla.com/D284550
We already require that this will outlive all child frames.
While we're here, reorganize a couple fields in nsSharedPageData to group data
smaller than a pointer together.
Differential Revision: https://phabricator.services.mozilla.com/D280110
Canvas uses CSS pixels, so this patch encodes the information into the type
system. Some painting code still uses unknown sizes, so we need to use
`CSSIntSize::FromUnknownSize` and `ToUnknownSize()` to convert them.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D216463
Where supported (print preview and print-to-PDF), this implements changing the
orientation and/or rotation of print sheets, as appropriate, in response to CSS
`page-orientation`. When supported we:
- in the single page-per-sheet case, rotate the sheet in order to implement
any `page-orientation` rotation on the sheet. Rotating the sheet is necessary
so that when we output PDF files the pages visually have the correct
orientation.
- in the multiple pages-per-sheet case, we already rotate individual pages in
their grid cell. This commit keeps such pages rotated, as appropriate, but
augments that behavior by switching the orientation of the sheet (based on
the first page on the sheet), if necessary, to make best use of the space on
the sheet. (We can't know what orientation any subsequent pages on the sheet
will have, so we assume the same orientation as the first one.)
Depends on D179423
Differential Revision: https://phabricator.services.mozilla.com/D179448
Where supported (print preview and print-to-PDF), this implements changing the
orientation and/or rotation of print sheets, as appropriate, in response to CSS
`page-orientation`. When supported we:
- in the single page-per-sheet case, rotate the sheet in order to implement
any `page-orientation` rotation on the sheet. Rotating the sheet is necessary
so that when we output PDF files the pages visually have the correct
orientation.
- in the multiple pages-per-sheet case, we already rotate individual pages in
their grid cell. This commit keeps such pages rotated, as appropriate, but
augments that behavior by switching the orientation of the sheet (based on
the first page on the sheet), if necessary, to make best use of the space on
the sheet. (We can't know what orientation any subsequent pages on the sheet
will have, so we assume the same orientation as the first one.)
Depends on D179423
Differential Revision: https://phabricator.services.mozilla.com/D179448
Where supported (print preview and print-to-PDF), this implements changing the
orientation and/or rotation of print sheets, as appropriate, in response to CSS
`page-orientation`. When supported we:
- in the single page-per-sheet case, rotate the sheet in order to implement
any `page-orientation` rotation on the sheet. Rotating the sheet is necessary
so that when we output PDF files the pages visually have the correct
orientation.
- in the multiple pages-per-sheet case, we already rotate individual pages in
their grid cell. This commit keeps such pages rotated, as appropriate, but
augments that behavior by switching the orientation of the sheet (based on
the first page on the sheet), if necessary, to make best use of the space on
the sheet. (We can't know what orientation any subsequent pages on the sheet
will have, so we assume the same orientation as the first one.)
Depends on D179423
Differential Revision: https://phabricator.services.mozilla.com/D179448
OS print drivers/devices know nothing about page dimensions unless we tell
them. Previously, the physical page dimensions (including orientation) have
always been the same, so communicating their dimensions once at the start of
a print has been enough. In preparation for supporting different "physical"
page dimensions (in the immediate future only different page orientations) when
we save to PDF, we need to have the infrastructure to pass dimensions through
on a page-by-page basis. This patch adds that.
None of the PrintTarget subclasses do anything with this extra information yet,
but in a follow-up patch PrintTargetPDF will use this information to create
PDFs with mixed page orientations.
Differential Revision: https://phabricator.services.mozilla.com/D179423
Where supported (print preview and print-to-PDF), this implements changing the
orientation and/or rotation of print sheets, as appropriate, in response to CSS
`page-orientation`. When supported we:
- in the single page-per-sheet case, rotate the sheet in order to implement
any `page-orientation` rotation on the sheet. Rotating the sheet is necessary
so that the pages in the PDF files that we output are correct.
- in the multiple pages-per-sheet case, we already rotate individual pages in
their grid cell. This change keeps such pages rotated, as appropriate, but
augments that behavior by switching the orientation of the sheet (based on
the first page on the sheet) if necessary to best place the page to make
maximum use of the space.
Depends on D179423
Differential Revision: https://phabricator.services.mozilla.com/D179448
OS print drivers/devices know nothing about page dimensions unless we tell
them. Previously, the physical page dimensions (including orientation) have
always been the same, so communicating their dimensions once at the start of
a print has been enough. In preparation for supporting different "physical"
page dimensions (in the immediate future only different page orientations) when
we save to PDF, we need to have the infrastructure to pass dimensions through
on a page-by-page basis. This patch adds that.
None of the PrintTarget subclasses do anything with this extra information yet,
but in a follow-up patch PrintTargetPDF will use this information to create
PDFs with mixed page orientations.
Differential Revision: https://phabricator.services.mozilla.com/D179423
OS print drivers/devices know nothing about page dimensions unless we tell
them. Previously, the physical page dimensions (including orientation) have
always been the same, so communicating their dimensions once at the start of
a print has been enough. In preparation for supporting different "physical"
page dimensions (in the immediate future only different page orientations) when
we save to PDF, we need to have the infrastructure to pass dimensions through
on a page-by-page basis. This patch adds that.
None of the PrintTarget subclasses do anything with this extra information yet,
but in a follow-up patch PrintTargetPDF will use this information to create
PDFs with mixed page orientations.
Depends on D179395
Differential Revision: https://phabricator.services.mozilla.com/D179423
This code doesn't change behavior itself. The same sheet size is cached on all
sheets. Patches for future bugs will change that.
Differential Revision: https://phabricator.services.mozilla.com/D179395
This code doesn't change behavior itself. The same sheet size is cached on all
sheets. Patches for future bugs will change that.
Differential Revision: https://phabricator.services.mozilla.com/D179395
The intention is to allow PrintedSheetFrame::Reflow to access the page style
prior to reflowing its child so that it can decide whether to apply page style
to the sheet (in the case of one page-per-sheet). This will happen in a
subsequent bug.
Differential Revision: https://phabricator.services.mozilla.com/D173773
This is to make GetDPIRatioForScrollbarPart thread-safe for stylo usage.
This was using the widget for bug 1727289, but just looking at the print
preview scale is enough to fix that.
Reviewed in: https://phabricator.services.mozilla.com/D168148
For that we need to:
* Make GetDPIRatioForScrollbarPart thread-safe: This was using the
widget for bug 1727289, but just looking at the print preview scale
is enough to fix that.
* Make nsPresContext::UseOverlayScrollbars() thread-safe: We store the
RDM pane stuff in the pres context.
The rest is pretty straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D168148
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
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
Emilio Cobos Álvarez