This also changes the function to return a sequence (JS Array) instead of
an nsFontFaceList object, and converts nsFontFace/nsIDOMFontFace into a
Web IDL implemented object too.
MozReview-Commit-ID: 1iAW3DYe5kO
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
EditorDOMPoint was a subclass of RangeBoundary. Therefore, for heavy
use of it in editor, we've implemented a lot of complicated feature
into RangeBoundary. However, EditorDOMPoint stopped inheriting
RangeBoundary. So, we can get simple RangeBoundary implementation
back now.
This patch makes RangeBoundary.h almost same as 3f7cbec2446b except
keeps implementing GetPreviousSiblingOfChildAtOffset() and
GetNextSiblingOfChildAtOffset() because the former is used by
Selection and both of them are simple. And also keeps making it
a friend of EditorDOMPoint because EditorDOMPoint still needs to
copy to/from RangeBoundary.
MozReview-Commit-ID: Hr5SA52ScK0
RangeBoundaryBase shouldn't compute mRef when it's initialized with offset.
E.g., some users of the template class may initialize it with a container and
offset in it but it may not refer mRef or may refer after modifying offset.
On the other hand, RangeBoundaryBase::InvalidateOffset() is a special method.
It assumes that mRef is always initialized when it's called but can be
invalidate mOffset until retrieved actually. This is necessary for
nsRange::mStart and nsRange::mEnd since the offset may be changed when
some nodes are inserted before the referring node.
So, now, InvalidateOffset() should be a protected method and make nsRange a
friend class of RangeBoundaryBase. Then, when nsRange sets mStart and/or mEnd,
nsRange itself should guarantee that their mRefs are initialized.
MozReview-Commit-ID: Alr4YkDXIND
This should really always test true, but apparently sometimes doesn't...
that's quite strange. Hopefully the diagnostic asserts will help pin down how
it can happen.
MozReview-Commit-ID: 4bxdalIaUnQ
Inserting/removing things into a doubly-linked list is much faster than doing
the same with a hashtable. Selection ranges register themselves on their common
ancestor, but all we do with that in non-debug code is iterate all the ranges
registered. A doubly-linked list works fine for that.
This adds three words to every range for the LinkedListItem members, but that
should be OK.
Inserting/removing things into a doubly-linked list is much faster than doing
the same with a hashtable. Selection ranges register themselves on their common
ancestor, but all we do with that in non-debug code is iterate all the ranges
registered. A doubly-linked list works fine for that.
This adds three words to every range for the LinkedListItem members, but that
should be OK.
This costs an extra word per range, but ranges aren't that small anyway. The
benefit is that we don't have to recompute it dynamically when we need it, which
lets us simplify how selection ranges get registered with their common ancestors.
nsIContentIterator::Init() takes nsRange but it's too expensive for some users.
So, there should be another Init() which can be specified a range in DOM tree
with 2 pairs of nsINode* and uint32_t.
MozReview-Commit-ID: 6JXic0KOM2d
Allocating and initializing nsRange is too expensive especially for temporary
use. However, ContentEventHandler uses nsRange only for representing two DOM
points. So, it should use simpler helper class, RawRange, for reducing some
unnecessary runtime cost.
Note that this still uses nsRange for initializing nsIContentIterator. This
will be fixed by the following patch.
MozReview-Commit-ID: 5TUy6yJf7HA
Per spec, Range.prototype.extractNodes() should copy the nodes in tree
order:
https://dom.spec.whatwg.org/#dom-range-extractcontents
Gecko instead copies them in reverse order. This causes us to fail a
wpt MutationObserver test.
MozReview-Commit-ID: 8MYXGhDsJCd
If a range endpoint is in the middle of a text node, and you call
deleteContents() or extractContents(), the spec says to delete the data
from the node. In the case of extractContents(), the new text node
that's inserted into the DocumentFragment is a clone with its data set
to the bit that was deleted.
<https://dom.spec.whatwg.org/#dom-range-deletecontents>
<https://dom.spec.whatwg.org/#dom-range-extractcontents>
We don't do this. Instead, we split the text node. Then the bit to
delete is deleted naturally at a later stage together with all the other
nodes.
The result is the same, but on the way there we do a bunch more node
mutations. This causes extra mutation records, which cause us to fail a
WPT test. Chrome passes. Changing to match the spec actually reduces
our lines of code anyway.
MozReview-Commit-ID: FTTV5yNSj71
DOM Standard defines that offset of Range is unsigned long. However, nsRange uses int32_t to them.
This patch makes nsRange use uint32_t instead. However, this patch does NOT allow to set over INT32_MAX as offset values since a lot of users of nsRange cannot treat the values as over INT32_MAX because a lot of internal APIs take int32_t as offsets.
For easier to search such points, this patch adds static_cast<int32_t> to uint32_t variables when they are used for int32_t arguments.
And note that nsContentUtils::ComparePoints() behaves odd. It accepts negative offset and compares such value with valid offset simply. This patch still uses int32_t offset variables in nsRange::CompareNodeToRange() even though it may be negative value if nsINode::IndexOf() returns -1 because the caller of it depends on this behavior.
MozReview-Commit-ID: 8RbOgA86JuT
`nsRange` registers mutation observers to adjust the range when content
changes. However, there are some cases where we adjust the start and/or
end offsets but don't notify selection listeners (i.e. we don't call
`nsRange::DoSetRange` to set the new range points, contrary to what the
comment above `nsRange::DoSetRange` says). This patch makes us call
`nsRange::DoSetRange` in those cases. The patch adds a testcase in
test_selectevents.html, and changes a few unexpected-pass cases in
test_composition_text_querycontent.xul that this patch fixed.
MozReview-Commit-ID: 73D8RYMS3MS
This does NOT change variable names like |endNode| because it's not odd and somebody use it for nsINode and endContent for nsIContent. So, changing them needs more work.
MozReview-Commit-ID: 22imUltlu5R
This does NOT change variable names like |startNode| because it's not odd and somebody use it for nsINode and startContent for nsIContent. So, changing them needs more work.
MozReview-Commit-ID: H19pTDprRuT
