Below list is animation test cases remain in test_animation_observers_async.html
* single_animation : waiting for animationend event
* single_animation_cancelled_fill : waiting for animaitonend event
* tree_ordering : waiting for animationend event
* coalesce_change_cancel : testing a non-cancelling change to an animation
followed immediately by a cancelling change sends only one removal
notification, I am concerned that adding explicit style flush
(e.g. getComputedstyle) might change the test purpose.
* play : redundant play() seems to be affected by asynchronous.
I haven't dug into detail.
* finish_from_pause : waiting for Animation.ready to make sure pause pending
state to finish.
MozReview-Commit-ID: HAelOTwSqgv
--HG--
extra : rebase_source : 819e8975028f62580dccd07fedc53d250b71f97a
Below list is transition test cases remain in test_animation_observers_async.html
* single_transition : waiting for transitionend event
MozReview-Commit-ID: 5ecgpJm1W6p
--HG--
extra : rebase_source : d5c77cf77521f62a693897230d73287deab8b6c7
Revert the work-around from bug 1421635 now that the upstream
fix is applied.
MozReview-Commit-ID: GwmXr8zVBGn
--HG--
extra : rebase_source : 253428fac503e8820856b371e44aaa963e932e29
Thanks to David Major for crash analysis and finding the fix.
Backport of upstream commit 15269e6e9288a6ed655c2ee73be6fbb4e0ea3cf5
by Yaowu Xu <yaowu@google.com> Mon Oct 16 10:48:55 2017 -0700
Align more restoration work buffers
Fixes crashes on x86-win32-vs14 build
Change-Id: I045dd0fe4e9af3bfb80223e291617b717cbcb231
MozReview-Commit-ID: 1p3tKFVnIfT
--HG--
extra : rebase_source : e0d20b3d8d36b9462b9de3fd800a7e07c11b1043
This is a follow up of #19077
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
Source-Repo: https://github.com/servo/servo
Source-Revision: ff70c4426d9ea2f36dc18216678f743e9f56f561
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : a54b8a720c19fdb3b5850b48e8f371a0fb8468df
This speeds up taskgraph generation by ~6 seconds on my machine. Future
improvements are also planned for 'fast' mode.
MozReview-Commit-ID: CLORvLXuV8y
--HG--
extra : rebase_source : a59dc5f166eff15e5031f5736eadac41dcd46ffe
We need to feed deinterleaved data, not interleaved data.
MozReview-Commit-ID: 99z8HA7tJgT
--HG--
extra : rebase_source : 686295cead6632688d7dc130b7904bf771b10bc3
It has been removed from the spec: https://github.com/whatwg/html/issues/336
See also https://github.com/servo/servo/pull/19471#pullrequestreview-80711878
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e3056d0cc7caebc218d51373b3aa0ccd331fa20
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 76bd32c1d97be56bee2675857fcb5b20f2ed2d42
This also fixes the vertical offset because we take the correct branch in the yDiff if block lower down.
MozReview-Commit-ID: KbHkRx1575X
--HG--
extra : rebase_source : ed9189c10dd00badb4bce9982a7ba20b647cef98
This is to make the header file more concise.
MozReview-Commit-ID: 7RFkppBdvbU
--HG--
extra : rebase_source : 29776b51e0ca9d0671bda208b84977b44d97bb22
extra : intermediate-source : 317d238af4025e64b8af61488fada9ec3d0b05c7
extra : source : 59d7baf15160231a53c459a3912e2c1430a1fa0e
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 : 6b84da35fdc96ae8161552fe5d0764b0c2c0f3ee
extra : intermediate-source : 88df2caad42694dd77f2a518ea8d460d6c88b8c6
extra : source : b920088860904c5d28f3dd2f6eda790dc09be003
While aborting conversion, we need to make sure there is no coversion task
executing in the PDFium process before destroying it.
MozReview-Commit-ID: 3Iqhe8KmYv2
--HG--
extra : rebase_source : b82fe3b7231d9c4a171d6a19cd22c0c7ff47b4bf
extra : source : 753ed705666fd4c55da456fb80604e4552d6bd52
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 : d12161e1c8ac6469fc1ecb9514939bd35979d573
extra : source : 70ce23becf8840408cd72e7f933a167090519c09
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 : 3531dd6a100e9518d8cb9904326250a8318cdad2
extra : source : f61eb00f83acf45511d8448922212dccb12b05aa
We integrate PrintTargetEMF with the PDFium process to convert PDF into EMF in
this patch.
MozReview-Commit-ID: 5F0setrL94n
--HG--
extra : rebase_source : 576e077f804785da20923620d9c4e3041936e835
extra : source : 28f1671230fa70125e6971c9a287cb0658b89496
A new subclass of PrintTarget.
1. It uses PrintTargetSkPDF to generate one PDF FileDescriptor for one page.
2. In a later patch, it then passes that FD to PDFium process for converting
a PDF page to EMF contents.
Implementation of integration with PDFium actor is added the subsequent patches.
MozReview-Commit-ID: EcuBJHRW8Wk
--HG--
extra : rebase_source : f977e6863b9f2ee961648ddaf13f5e30a3659410
To move EMF conversion job to a dedicated process, I will implement a new
PrintTarget subclass, named PrintTargetEMF, to coordinate tasks among the
content process, chrome process and PDFium process. All the code that we
change in nsDeviceContextSpecWin is no longer needed.
MozReview-Commit-ID: GgKZoB92WYE
--HG--
extra : rebase_source : 1687d72a8fe88223f17c954c23022236dfe029a0
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : b6459a187de8e066e7574d2b8757d09fbcfcddba
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
This is to make the naming more consistent with SavePageToBuffer.
MozReview-Commit-ID: 5miYvv9yFFR
--HG--
extra : rebase_source : 07d1f72b33f962622a843355da6d3067a286483a
With the help of these new function, we can serialize/deserialize EMF content
in/out a share memory object.
MozReview-Commit-ID: Dm45xEXmMqS
--HG--
extra : rebase_source : 8203924d873509ccb2d869bf1b427afb6afb718e
extra : source : 61f81b148f8b1d1569d7cf279575b38f4570171f
All the functions added in Part 2 are utilities for sharing EMF/PDF contents
between processes.
MozReview-Commit-ID: 3qKosXH56kY
--HG--
extra : rebase_source : 0531cfa563094c1a3a6dac4895ed1b8edfd285e0
extra : source : b61b651ed6f668e32176353d346b25d23e2cd932
We will create several new files in the following patches for IPC and a new
subprocess. Several already existed files will be shifted into new build units,
we will meet several compile errors because of it.
This patch fixes those compile error in advance.
MozReview-Commit-ID: 5hd0sNYfBu0
--HG--
extra : rebase_source : b6b8b069f8f2167ef87266ba9c95e8fe53cca6f6
Hiroyuki Ikezoe
Emilio Cobos Álvarez
Ralph Giles
Noemi Erli
Zibi Braniecki
Milan Sreckovic
Francesco Lodolo (:flod)
Jed Davis
Fernando Jiménez Moreno
Bogdan Tara
Andrew Halberstadt
Tim Nguyen
Paul Adenot
Jon Leighton
Ionut Goldan
Rob Wood
Gijs Kruitbosch
cku