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
nsRange::DoSetRange() adds/remove its root to/from mutation observer, initializes common ancestor, registers itself to the common ancestor, unregisters itself from old common ancestor, and notifies selection listeners of selection change.
However, those runtime cost is expensive but on the other hand, a lot of callers set both start and end of the range and that causes calling DoSetRange() twice.
This patch renames Set() to SetStartAndEnd() for easier to understand the meaning and make it call DoSetRange() only once.
MozReview-Commit-ID: FRV55tuBAgg
In the next patch we want to add a method called
GetUnanimatedStyleContextForElementNoFlush but that's much too long. Instead it
seems better to just drop 'ForElement' from all these methods since it should be
fairly obvious we are getting the style context for an element given that the
first argument is an element.
MozReview-Commit-ID: JQKaEuCKV2F
When nsRange::*JS() is called, mCalledByJS is set to true. In such case, Selection::NotifySelectionListeners() may move focus or anyway, it calls selection listeners. Then, they may cause calling non-*JS() methods of the nsRange instance. In this case, nsRange treats the call as called by JS since mCalledByJS is still true.
For preventing this issue, before calling Selection::NotifySelectionListeners(), nsRange should set mCalledByJS to false.
This patch renames AutoCalledByJSSetter to AutoCalledByJSRestore and make it stop setting mCalledByJS automatically. So, AutoCalledByJSRestore works same as AutoRestore now.
MozReview-Commit-ID: IYsbQTGp3VA
Selection may be changed by methods of Selection or methods of Range retrieved by Selection.getRangeAt(). Selection::NotifySelectionListeners() is called after every selection change of each of them, so, this method must be a good point to move focus.
If new common ancestor of all ranges is editable and in an editing host, we should move focus to it. Otherwise, if an editing host has focus but new common ancestor is not editable, we should move focus from the editing host.
For consistency with the other browsers, this patch doesn't move focus to other focusable element.
MozReview-Commit-ID: 6sNsuzwqECX
Selection needs to be able to distinguish if every selection change is caused by JS (i.e., via Selection API) or the others.
This patch maps some methods of Range and Selection to *JS(). Each of them marks its instance as "used by JS" and calls corresponding method.
With this change, Selection::NotifySelectionListeners() can move focus only when it's caused by Selection API.
MozReview-Commit-ID: 1GoLHiIJ10Y
