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 : 838d798161e112952b5e148bbece730159cd49ca
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 : 4b1999bd83306dce162f76bd5e46015113a52e2b
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 : c64c4d39ccca16271959ade57edc2a8a087141b8
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 : d0a433e55a1a919a4207aee5f2fee9e75bd0a36e
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 : a84834075aa58099104ba9cdaa375da4b973c23b
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 : 677bf9f30399f28e1e094843448c133b0c2391a7
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 : d4cca529623586188ffebffd858f53188d12bb50
The selection API only applies to certain <input> types:
https://html.spec.whatwg.org/multipage/#do-not-apply
This commit ensures that we handle that correctly.
Some notes:
1. TextControl::set_dom_selection_direction now calls
set_selection_range(), which means that setting selectionDirection will
now fire a selection event, as it should per the spec.
2. There is a test for the firing of the select event in
tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/select-event.html,
however the test did not run due to this syntax error:
(pid:26017) "ERROR:script::dom::bindings::error: Error at http://web-platform.test:8000/html/semantics/forms/textfieldselection/select-event.html:50:11 missing = in const declaration"
This happens due to the us of the "for (const foo of ...)" construct.
Per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of
this should actually work, so it's somewhat unsatisfying to have to
change the test.
3. I removed tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/selection-not-application-textarea.html
because it doesn't seem to add any extra value - the selection API
always applies to textarea elements, and the API is tested elsewhere.
4. If an `<input>`'s type is unset, it defaults to a text, and the
selection API applies. Also, if an `<input>`'s type is set to an
invalid value, it defaults to a text too. This second case doesn't
currently work, and I'll need to do more restructuring of the code in
a future commit. See discussion with nox in IRC:
https://mozilla.logbot.info/servo/20171201#c13946454-c13946594
Source-Repo: https://github.com/servo/servo
Source-Revision: db41cc00be93523114092125859534b107ec772a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 1ac0a74fcea1cfc06a94607896101667847e727c
The branch is based off serde 1.0.23 and includes additional changes for faster
enum deserialization which we want for WebRender. The changes are in the process
of being upstreamed but will take a while.
MozReview-Commit-ID: 4xaPQpffzYL
mDecodedAudioDuration should only save unadjusted timestamp, or it would
cause next adjustment to be incorrect.
MozReview-Commit-ID: 7grtYs075p0
--HG--
extra : rebase_source : ad146e7c34b6154629c1ff98992d5c0209d3ef80
Provide an explanatory error message when the compilation would fail because of missing or duplicate items.
Source-Repo: https://github.com/servo/servo
Source-Revision: 29d960ee5c043ba87ec0da565b5d61979a8a9b78
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 938036878f0738eb87e98a6f70a0f031d465b240
This turns the ATOMIC_PTR macro into a function and merges the
prepareMemoryAccess() call into that function, for a nice net cleanup
+ movement of platform code.
(This would be even prettier with C++14 automatic return type
deduction but that is a "not yet" feature.)
MozReview-Commit-ID: JwWOQIli5sS
--HG--
extra : rebase_source : 2bb52ba983455c7a1cef0fa47303e73b1f2704a9
Different from RangeBoundaryBase, EditorDOMPointBase can store only child node.
I.e., mOffset may be invalid until its Offset() is called. So,
GetChildAtOffset() isn't good name. It should be just GetChild().
Similarly, GetNextSiblingOfChildAtOffset() and
GetPreviousSiblingOfChildAtOffset() should be renamed to GetNextSiblingOfChild()
and GetPreviousSiblingOfChild().
MozReview-Commit-ID: WpkPmDwkrL
--HG--
extra : rebase_source : 2be1fcbee129f4c96e9b166be5a924845340708f
EditorDOMPointBase::Container() may return nullptr. So, it should be renamed
to GetContainer().
Then, the method name becomes longer and a lot of callers access the result
directly. So, there should be following methods to make the callers shorter:
- GetContainerAsContent() to return the container as nsIContent*.
- GetContainerAsElement() to return the container as dom::Element*.
- GetContainerAsText() to return the container as dom::Text.
- GetContainerAsDOMNode() to return the container as nsIDOMNode*.
- CanContainerHaveChildren() to check if the container can have child nodes.
- IsInDataNode() to check if the point is in a data node including text node.
- IsInTextNode() to check if the point is in a text node.
- IsContainerHTMLElement() to check if the container is specific HTML element.
- IsContainerAnyOfHTMLElements() to check if the container is one of the
specified HTML elements.
MozReview-Commit-ID: LkN2WBbCPj0
--HG--
extra : rebase_source : 9da1e70d4c74f7ad573e244cf6c7b21a0c7b4410
Editor code sometimes sets a DOM point to end of a node. In this case, we
need to write |Set(node, node->Length())|. So, it should have
|void SetToEndOf(const nsINode* aContainer)| for making meaning of the code
clearer.
MozReview-Commit-ID: 91shMCD2d84
--HG--
extra : rebase_source : 3401af50aabc1b677deeae664e8c56506182d28c
Even after EditorBase::DeleteSelectionAndCreateElement() creates a new element,
it tries to collapse selection with |pointToInsert| which is outdated after
inserting new element.
So, it should recompute the caret position with new DOM tree.
MozReview-Commit-ID: DKh2uhItIol
--HG--
extra : rebase_source : c0c30e1c809784af64e87596b471c472350857a8
nsRange::SetStart(), nsRange::SetEnd(), nsRange::IsPointInRange() and
nsRange::ComparePoint() take a set of container node and offset in it to
specifying a DOM point. However, the caller may not have computed the offset
but may know the child node at the point. In such case, they can avoid
computing the offset with nsINode::IndexOf() if they have overloads which
take RawRangeBoundary.
Therefore, this patch implements the overloads and changes the callers in
editor.
MozReview-Commit-ID: E4DLbAgTTCI
--HG--
extra : rebase_source : 8d1632a030f1e0a0dd2b81c3996c19d427e8b0bd
Some methods of editor retrieves anchor and focus of selection. However, there
are no methods which directly access RangeBoundary of anchor and focus.
This patch adds it for making editor code simpler and avoiding unnecessary
child offset computation.
MozReview-Commit-ID: EvepQpFMi8S
--HG--
extra : rebase_source : 38f3c506db5c9d8790bbd625d552bfbc8d99cebc
HTMLEditor::NormalizeEOLInsertPosition() takes a set of container node and
offset in it for specifying insertion point. So, this should be replaced
with |const EditorRawDOMPoint&| and it should return |EditorDOMPoint| rather
than modifying the argument.
Additionally, perhaps, GetBetterInsertionPointFor() is better name for it.
MozReview-Commit-ID: IB1FhrkzK2G
--HG--
extra : rebase_source : 55f8c1d9fa1f149e81114c929f6e6232aba03905
With one exception this removes all platform ifdefs from the high
level of the atomics code generators by moving the register targeting
into RAII wrappers. These wrappers are placed in the new section of
the file, introduced by the previous patch. These wrappers also get
rid of several of the needWhateverTemp() functions because they are
rolled into the RAII wrappers.
The exception is 64-bit atomic ops on x86: here, we are always starved
for registers and must use slightly different APIs, but most of the
code is common and there's a clear pattern at work, so I don't think
this is bad.
Each wrapper carries a method implementing the operation that the
wrapper is for, and calls lower-level code to implement the operation
with appropriate arguments. Thus details of the wrapper are hidden,
and there's minimal risk of abuse or accident.
MozReview-Commit-ID: HeqgqrImxms
--HG--
extra : rebase_source : 73c743bca17dc365e816c64cc2c609dcc3912e09
cku
Jon Leighton
Ryan VanderMeulen
ffxbld
Olli Pettay
Blake Kaplan
Kartikaya Gupta
Glenn Watson
Alastor Wu
Ciure Andrei
Simon Sapin
Tooru Fujisawa
shindli
Kyle Machulis
Lars T Hansen
Fred Lin
Masayuki Nakano