page-rule-specificity-001-print.html is the only test that actually fails prior
to this patch (it already passes in Chrome).
Differential Revision: https://phabricator.services.mozilla.com/D196000
page-rule-specificity-001-print.html is the only test that actually fails prior
to this patch (it already passes in Chrome).
Differential Revision: https://phabricator.services.mozilla.com/D196000
page-rule-specificity-001-print.html is the only test that actually fails prior
to this patch (it already passes in Chrome).
Differential Revision: https://phabricator.services.mozilla.com/D196000
Until recently the only place that checked this pref was the Firefox front-end
code, and it communicated to use the CSS page size as the "paper" sheet size
for PDFs by setting nsIPrintSettings.usePageRuleSizeAsPaperSize. This was
expanded in bug 1866319 to make WPT also ask for the same behavior. However,
there are other places that are failing to ask for this.
Rather than play whack-a-mole to fix up the entry points to PDF printing, this
moves the pref check to the platform code.
The one situation that I'm not changing the pref to work in is when Firefox is
running ond Android. That's just because it's not currently clear to me what
the fallout is of Firefox on Android potentially creating PDFs with different
sheet sizes, and I don't want us to potentially deal with negative fallout as
we're finishing up the Gsuite work in December.
For now, I'm also refraining from removing
nsIPrintSettings.usePageRuleSizeAsPaperSize just in case we run into issues
(not very likely on non-Android) and want to temporarily restore the old
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D195181
The old name is potentially misleading now that we implement 'page-orientation'
since that provides a new mechanism by which pages could end up orthoganal
to the sheet, but this method is very specifically about pages-per-sheet
induced rotation.
Differential Revision: https://phabricator.services.mozilla.com/D193989
This patch adds a new layout profiling sub-category "LAYOUT_Printing" for the
markers added here.
I'm adding an "interval"-type marker ("AUTO_PROFILER_MARKER_TEXT") for the
function-calls that seem likely to occupy measurable amounts of time (due to
touching the filesystem or printer driver), vs. single-point-in-time markers
("PROFILER_MARKER_TEXT") for functions whose duration isn't particularly long
or interesting, or whose durations we're already measuring with other
closely-associated interval-markers.
Differential Revision: https://phabricator.services.mozilla.com/D191001
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
Adds a usePageRuleSizeAsPaperSize setting to allow overriding the default paper size when printing to a PDF file.
Print preview now checks for at-page size rules and when enabled will use that size for the previewed sheet of paper.
The preview will also return the page width and height (in inches) during its callback for the frontend to use to override the default paper settings.
Differential Revision: https://phabricator.services.mozilla.com/D160303
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Basically, we notify the media feature values changed when creating a
new preshell. For the print job, we have to set the page size, the
visible area, and set mIsRootPaginatedDocument before doing this
notification, so we can get the correct viewport size and use it to select
the correct responsive image source, in print preview of the top level
document.
Note: I intentionally set mIsRootPaginatedDocument earilier than visible
area to avoid a potential redundant notification because we notify the
media feature values changed for all changes when creating a new preshell
as well.
Differential Revision: https://phabricator.services.mozilla.com/D165089
All implementors currently simply resolve the promise right away, using
crutch code. Asynchronous usage will be added in the changeset that follows.
Differential Revision: https://phabricator.services.mozilla.com/D163508
The @page rule may contain both 'page-orientation' and 'size' properties. The
'size' property can contain an orientation component which was being
represented as 'PageOrientation' prior to this patch. This patch changes that
to 'PageSizeOrientation' so that 'PageOrientation' can be used for
'page-orientation' in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D160790
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 does not change behavior (other than a minor correctness fix in some
off-by-default logging; see below).
As shown in the removed line of the init list, this mFrameType member-var's
semantics are equivalent to a null-check of the mParent member-var. So: rather
than encoding that same information twice, this patch simplifies to just
directly null-check the mParent pointer at all the usage sites.
Before this patch, nsPrintJob.cpp had two different patterns for logging
mFrameType; sometimes with a global `gFrameTypesStr` array, and other times
with a local `types` array (with shorter 2-character strings). I've converted
both of these to helper-functions.
In the case of the `types` array, the old code used a 4-value array, which was
interesting since the enum type only had 2 possible values. This discrepancy is
just due to an oversight in bug 1769508, where we recently condensed the enum
from 4 values to 2; that bug technically should've condensed these arrays as
well (but didn't do so). This left these arrays' enum-to-string mapping being
wrong (since eIFrame changed its numeric value from 2 to 1 in bug 1769508), but
probably nobody has used this logging code in a while, so nobody
noticed. Anyway: in this patch, I'm restoring the mappings that we had before
that change (so we'll log "DC" for root print objects and "IF" for non-root
i.e. iframe-flavored print objects).
Differential Revision: https://phabricator.services.mozilla.com/D150177
This patch doesn't change behavior; it's just refactoring.
The pre-existing Init code is now clearly infallible, now that earlier patches
have removed all of Init's NS_ENSURE_STATE arg-null-checks (which were Init's
only failure-returning codepaths).
So: now that it's infallible, we can just merge the Init() code directly into
the constructor.
This lets us promote some member-variables to be 'const' as well, since they
will now be initialized in the init list and are never modified after that.
Differential Revision: https://phabricator.services.mozilla.com/D150079
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
This patch doesn't change behavior.
The two init functions were already pretty similar. This patch merges them,
and uses the "aParent" arg as a signal for which variant we're handling (with
the "root" variant being signalled via a null value).
This usage of aParent (to distinguish between variants) is valid, as long as we
can assume that the old `InitAsNestedObject` variant was always guaranteed to
receive a non-null value for its aParent arg. (That would mean that we're OK to
use that arg's nullness as a way to distinguish between the two variants in
their new merged form.)
And indeed, we're safe to make this assumption, since there's only one callsite
for the `InitAsNestedObject` version (which is in
`nsPrintJob::BuildNestedPrintObjects`), and it dereferences the pointer before
calling into this init function. So, the pointer has to be non-null, or else
we would have crashed at the earlier dereference.
Therefore, this conversion (and usage of aParent to distinguish between
variants) is valid.
(Spoiler alert: a later patch in this series will merge this Init() method
into the constructor. I'm doing this as a multi-step process with this
intermediate state, in order to hopefully make it easier to reason about the
conversion and confirm that it's valid.)
Differential Revision: https://phabricator.services.mozilla.com/D150077
This patch doesn't change behavior.
The assignment here is working with a freshly-constructed `nsPrintObject`,
which was initialized via `InitAsRootObject`. Its `mFrameType` will have
already been assigned to `eDoc` in the constructor. The only place in our
codebase where we might hypothetically reassign `mFrameType` is in
`InitAsNestedObject`, but that's the other init method -- not the one we're
calling here.
So: `mFrameType` will already be `eDoc` when we reach this assignment, and
the assignment is unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D150076
We're seeing a lot of null crashes here. Maybe we're running script since
we last checked mPrintObject and the printer was disconnected or
something along those lines, so just add a null check.
Differential Revision: https://phabricator.services.mozilla.com/D149387
