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
This creates a new section in the file that sits between the low-level
code generators (above) and the high-level logic and value stack
manipulation (below). The intent is that this section will contain
platform-specific helpers for register targeting when we pop the value
stack.
As explained in a new comment in the code, there are two types of
helpers: simple popXForY methods, of which we've had many; and RAII
wrappers. I've moved the existing popXForY methods into this
section in this patch; the next patch introduces a number of RAII
wrappers.
MozReview-Commit-ID: Fq6TqgsFOkL
--HG--
extra : rebase_source : bd35fe8a835196bb115153042dc73074e788acfc
Given the standard wasm limits for parameters and locals, and assuming
a reasonable limit for the max evaluation stack height, we see that we
need a static frame size around 512KiB in the worst case.
The old limit, 256KiB, was arbitrary (it was just a large number meant
to reduce the attack surface) and we can therefore increase it to
512KiB.
MozReview-Commit-ID: JcKEdEp20Ok
--HG--
extra : rebase_source : 32f78f25f9d9ea369489b7d9a260d29fa8d49859
HTMLEditor::InsertNodeAtPoint() should take |const EditorRawDOMPoint&| as
an argument which specifies point to insert. Additionally, it should take
|EditorDOMPoint*| to return the next point of actual insertion point.
Additionally, this patch renames it to InsertNodeAtProperAncestor() for
explaining what it will do.
MozReview-Commit-ID: HYUzSlyPxAd
--HG--
extra : rebase_source : 57033cdc4458b45a5fe9d6aa642c185133a79304
Although nsIEditActionListener::WillInsertNode() nobody implements actually,
we should remove it in a follow up bug.
nsIEditActionListener::DidInsertNode() is implemented only by HTMLEditRules.
So, if we make it not use nsIEditActionListener, we can remove it too.
However, keep it for now.
On the other hand, they don't need to receive index of the insertion point.
WillInsertNode() needs next sibling of the insert point, but DidInsertNode()
needs nothing because listener can compute it with new inserted node.
MozReview-Commit-ID: GiTKkVyZJlN
--HG--
extra : rebase_source : 9ee38c28217d25d1a3f79b0b458c7b2121350a76
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt
EditorBase::CreateTxnForInsertNode() and EditorBase::InsertNode() should take
|const EditorRawDOMPoint&| as an argument specifying point to insert.
MozReview-Commit-ID: KhK19xS7wXb
--HG--
extra : rebase_source : f7b08b7d049eef8a9c03ee681e53e8d469915b15
Like CreateNodeTransaction, InsertNodeTransaction should use EditorRawDOMPoint
for temporary variable and arguments of its methods and should use RangeBoudary
to store it as its member.
MozReview-Commit-ID: FCGY8x97egb
--HG--
extra : rebase_source : bd5ce45944b8b367afc9b782e881727061d83035
I'll need this for ::slotted().
Source-Repo: https://github.com/servo/servo
Source-Revision: c6bf85eca90b9cb71ff05d4454a43a7da5fc3ac8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 02f9868af7469734b70d02e8ddb0470a9c8d407d
This is stable in Rust 1.22 (#19532).
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because it is refactoring only
Source-Repo: https://github.com/servo/servo
Source-Revision: 5f4f355cea4a24992ac9efa97f4a6e1837008e0b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 3a61f3b466e9f3c80f94b7ecb30f70f85efa55b3
Also drop a few FIXMEs while at it, since they look bogus.
Source-Repo: https://github.com/servo/servo
Source-Revision: 051eb6bcb9204ecab1c1481a275a09fd50bf0467
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 049f90ddd1ae37e05adec201fbaa6f876cbdddfe
Kyle Machulis
Lars T Hansen
Fred Lin
Masayuki Nakano
Ioana Crisan
Dragana Damjanovic dd.mozilla@gmail.com
Stone Shih
Thom Chiovoloni
Emilio Cobos Álvarez
Sebastian Hengst
Andreea Pavel
ffxbld
Matt Brubeck
Gurzau Raul
Aaron Klotz
Gabriel Luong
Nicolas B. Pierron
Ben Kelly