This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
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
For the last page, here is the final three messages sent between the content
process, RemotePrintJobChild, and the chrome process, RemotePrintJobParent, for
printing:
1. The content process sends *ProcessPage* to the chrome process via
SendProcessPrint to request the chrome process print the last page.
2. The content process sends *FinalizePrint* to the chrome process via
SendFinalizePrint to notify the chrome that there are no more outstanding
print requests, and that the chrome process can release interal resource
now.
3. The content process receive PageProcessed message from the chrome process.
This calling sequence is fine for sync style PrintTarget (even though the
FinalizePrint message is sent out a bit ealy). Since a sync PrintTarget
completes its print task right after receiving *ProcessPage* message in #1,
sending FinalizePrint before getting PageProcessed response is harmless.
But this message dispatching sequence does cause a problem for async style
PrintTargetEMF. After getting a message sent in #2, PrintTargetEMF release all
resources before getting a EMF conversion response from the PDFium process. So
the last page can not be printed correctly. This patch reorder the #2 and #3
message, that is to send FinalizePrint after the content process received
PageProcessed message of the last page.
MozReview-Commit-ID: 9ZVSrFnuHBU
--HG--
extra : rebase_source : a54b264998abeeeb0814768e1dd3f6749de97def
extra : source : 70ce23becf8840408cd72e7f933a167090519c09
