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
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 avoids exposing the path to potentially compromised content processes.
The roundtripping of the toFileName value from RemotePrintJobParent's
mPrintSettings to the content process and then back to
RemotePrintJobParent::InitializePrintDevice was silly anyway.
Differential Revision: https://phabricator.services.mozilla.com/D146867
Bug 1757395 basically removed the reason for PPrinting to exist. What remained
essentially just added an unnecessary layer of complexity/indirection to the
creation of PRmotePrintJob actors.
Differential Revision: https://phabricator.services.mozilla.com/D143330
IsSyncPagePrinting() only had one implementation which unconditionally
returned true.
So, any code that was conditioned on !IsSyncPagePrinting() is necessarily
dead/unreachable.
These are also crashing due to a null deref in mPrintTarget which might
happen if print is aborted.
Differential Revision: https://phabricator.services.mozilla.com/D140988
This is a mechanical change which was performed by a script based on the
contents of direct_call.py, and then manually checked over to fix
various rewriting bugs caused by my glorified sed script. See the
previous part for more context on the change.
Differential Revision: https://phabricator.services.mozilla.com/D137227
Make nsIWebBrowserPrint included unconditionally for addressing nsIDocShell.rs build failure.
Remove direct_call of PPrinting and PRemotePrintJob. Their ipdl are built unconditionally, but their derived classes are not built with --disable-printing.
Differential Revision: https://phabricator.services.mozilla.com/D33391
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
This fixes PrintTargetWindows::BeginPrinting to detect when the
user cancels and have it return NS_ERROR_ABORT in that case.
The rest of the changes are simply making sure that the various
call points up the call stack don't print a warning message if
NS_ERROR_ABORT is returned up from
PrintTargetWindows::BeginPrinting.
MozReview-Commit-ID: 6xZ5SPje6TT
After the part 1 fix, we can still (asynchronously) call some generic cleanup
code that tries to let the parent process's RemotePrintJobParent know that
printing failed under the stack:
RemotePrintJobChild::OnStatusChange
nsPrintData::DoOnStatusChange
nsPrintJob::FirePrintingErrorEvent
nsPrintJob::CleanupOnFailure
We crash on trying to use the RemotePrintJobChild to message the parent process
since the delete message from the parent has been processed. This change makes
RemotePrintJobChild::OnStatusChange check that it's initialized before trying
to send any messages.
Pushing to CLOSED TREE since this passed a full Try build and is a topcrash
we want to land for beta ASAP.
MozReview-Commit-ID: FfizRMj2s2m
If the content process which is printing target content is closed
during printing, PrintProgressService will continue to display
progress dialog even if Cancel is clicked.
This patch will:
* If IPC connection is closed, notify to PrintProgressService via
nsIWebProgressListener.
MozReview-Commit-ID: DoOfJjnk1wJ
--HG--
extra : rebase_source : 861d36fca15fe156645235cdc77bc9461363a0b0
If in the future nsDeviceContextSpecWin::BeginDocument was to return
NS_ERROR_FAILURE, then the channel between RemotePrintJobParent and
RemotePrintJobChild will be close at [1]. RemotePrintJobChild keep using ipc
calls after the channel is broken and hits assertions.
PS:
We always hits this assertion by forcing nsDeviceContextSpecWin::BeginDocument
returning NS_ERROR_FAILURE. It's not relative to the change we made in
previous patches.
[1]
https://hg.mozilla.org/mozilla-central/file/b186fddce27f/layout/printing/ipc/RemotePrintJobParent.cpp#l44
MozReview-Commit-ID: 79mZBf301nb
--HG--
extra : rebase_source : 58076a18be56d7eea37ea2f5a147db0048e3493f
extra : intermediate-source : 88df2caad42694dd77f2a518ea8d460d6c88b8c6
extra : source : b920088860904c5d28f3dd2f6eda790dc09be003
Before we introduce PrintTargetEMF, all PrintTargets finish page printing task
before the end of PrintTarget::EndPage(). Unlike others, a page printing
in PrintTargetEMF is done after receiving an async callback from the pdfium
process. So we have both async and sync page printing behavior now. This patch
is trying to make both of them work correctly while priting a content document.
MozReview-Commit-ID: 2PHJToFlvtu
--HG--
extra : rebase_source : 9d2d7cf7330a157a0e5c6a414c75de94ca3fb5a1
extra : source : f61eb00f83acf45511d8448922212dccb12b05aa
David Shin
Emilio Cobos Álvarez
Dmitrij Feller
Jonathan Watt
Nika Layzell
Butkovits Atila
Jens Stutte
Marian-Vasile Laza
Matt Woodrow
Dorel Luca
Kashav Madan
Simon Giesecke
Mats Palmgren
Bob Owen
sotaro
Alex Gaynor
Ehsan Akhgari
Sylvestre Ledru
Noemi Erli
Tiberius Oros
Chris Peterson
Mantaroh Yoshinaga
cku
Cosmin Sabou