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
This currently only includes block frames, grid containers, and flex
containers, and the document and pagination frames. It is possible more frames
will need to be added or more advanced checks in the future.
This adds some related tests to ignoring some subtrees, but are expected fails
until bug 1816570 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D169018
This currently only includes block frames, grid containers, and flex
containers, and the document and pagination frames. It is possible more frames
will need to be added or more advanced checks in the future.
This adds some related tests to ignoring some subtrees, but are expected fails
until bug 1816570 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D169018
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
Previously, we notified the listeners with a done event when `RemotePrintJobChild`
reported done, even if there is work left on the parent side.
Differential Revision: https://phabricator.services.mozilla.com/D163507
Unfortunately, this can be called through both reflow and frame construction
much like nsCSSFrameConstructor::ContentAppended, so we can't just use a page-
name tracker.
Differential Revision: https://phabricator.services.mozilla.com/D164760
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 prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
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
Move two assignments to the declaration site, and remove an unnecessary
nullptr assignment (for a nsCOMPtr which is nullptr by default).
Depends on D150079
Differential Revision: https://phabricator.services.mozilla.com/D150176
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
It has no parent or child classes, so there's no reason that any of its methods
(including its destructor) would be virtual. So it's more-confusing than
helpful to have an explicit "non-virtual" code-comment.
The `final` keyword on the class hopefully makes this more-clear.
Differential Revision: https://phabricator.services.mozilla.com/D150080
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
This avoids exposing printer names to potentially compromised content processes.
The changes in bug 1770211 mean that we no longer create platform specific
nsIDeviceContextSpec instances in the content process, so we no longer need
the printer name to instantiate an nsDeviceContextSpecWin there.
Differential Revision: https://phabricator.services.mozilla.com/D146868
Emily McDonough
Fred Chasen
Butkovits Atila
Jonathan Kew
Jan-Niklas Jaeschke
Sandor Molnar
Noemi Erli
Boris Chiou
David Shin
Frederic Wang
Otto Länd
Emilio Cobos Álvarez
Jonathan Watt
Daniel Holbert
Andrew McCreight
Dmitrij Feller