If the element is slotted and the aKind == TreeKind::Flat, it should
use the index of AssignedNodes of the slot element to do the
comparison.
Differential Revision: https://phabricator.services.mozilla.com/D249427
This reverts commit 0681b181d6.
Revert "Bug 1932150 - Fix lint failure" for causing Build bustage.
This reverts commit 60cc0878d3.
Revert "Bug 1932150 - Add new test cases for selection in flat tree r=smaug"
This reverts commit 3dbe5fc183.
Revert "Bug 1932150 - Make selection code to correctly iterate flattened tree r=smaug"
This reverts commit 6f7a1e4886.
Revert "Bug 1932150 - ContentSubtreeIterator #3: Fix a bug in ContentSubtreeIterator where the end container is in the light DOM of a shadow host r=jjaschke"
This reverts commit 19ce2c5806.
Revert "Bug 1932150 - ContentSubtreeIterator #2: Allow ContentSubtreeIterator to iterate nodes in flattened tree r=jjaschke"
This reverts commit d9d192bc3a.
Revert "Bug 1932150 - ContentSubtreeIterator #1: Make the end container related logic in ContentSubtreeIterator more robust r=jjaschke,smaug,dom-core"
This reverts commit 2fbde5b84d.
Revert "Bug 1932150 - Update ranges to correctly set and update nodes for flattened selection r=jjaschke,smaug,dom-core"
This reverts commit 116d26c37f.
Revert "Bug 1932150 - Allow using flat tree order for point comparing in selection r=jjaschke,smaug,dom-core"
This reverts commit 2ba73e1639.
Revert "Bug 1932150 - Fix some inconsistency about indicating whether the selection is allowed to cross the shadow boundary r=jjaschke,dom-core"
This reverts commit 793c2453f1.
Basically when getSelection().toString() is called, Chromium may
return an serialization on a different content than Firefox.
This patch tries to address this webcompat issue by mimicing
the same behaviour.
We should still address the spec issues, but this seems to be
an acceptable compromise.
Differential Revision: https://phabricator.services.mozilla.com/D239657
This patch fixes multiple points which may cross independent selection
boundaries which is element boundary of the native anonymous `<div>` for
editable content in text controls. The reason why I don't split this patch is,
fixing one of them leads another assertion failure. So, I couldn't pass all
tests with separated patches.
1. `nsFrameTraversal` should take `Element` instead of `nsIFrame` for the
limiter because e.g., inline editing host like `<span contenteditable>` may
have multiple frames if it's wrapped. Therefore, we should make it take
an element as the ancestor limiter, and check it when getting parent frame
or after getting previous or next frame.
2. `nsIFrame::PeekBackwardAndForward` may cross the boundary because it does not
take the anonymous `<div>` element as ancestor limiter of the selection. It's
currently used only for extending selection. Therefore, I rename it to make
it clearer.
3. `SelectionMovementUtils::GetPrevNextBidiLevel` to take the ancestor limiter
for calling `nsIFrame::GetFrameFromDirection()`.
4. `nsINode` should have a method to return the `nsFrameSelection` instance
which manages the selection in the node. This makes the check simpler, and
this is not expensive. Then, for making it clearer, I rename
`TextControlElement::GetConstFrameSelection()` to
`GetIndependentFrameSelection()`.
5. `nsINode::GetSelectionRootContent()` should have an option to return
independent selection root when the node is its host for
`nsFrameSelection::ConstrainFrameAndPointToAnchorSubtree()`
6. `nsFrameSelection::ConstrainFrameAndPointToAnchorSubtree()` should not
retrieve independent selection root when the given frame is a text control
frame.
7. `RangeUtils` should get parent with checking the independent selection
boundaries.
8. `Selection::Extend` should assert if the destination is managed by its
frame selection to detect a bug.
Differential Revision: https://phabricator.services.mozilla.com/D241587
Basically when getSelection().toString() is called, Chromium may
return an serialization on a different content than Firefox.
This patch tries to address this webcompat issue by mimicing
the same behaviour.
We should still address the spec issues, but this seems to be
an acceptable compromise.
Differential Revision: https://phabricator.services.mozilla.com/D239657
Basically when getSelection().toString() is called, Chromium may
return an serialization on a different content than Firefox.
This patch tries to address this webcompat issue by mimicing
the same behaviour.
We should still address the spec issues, but this seems to be
an acceptable compromise.
Differential Revision: https://phabricator.services.mozilla.com/D239657
Usually, we name methods as `GetFoo()` if they may return `nullptr`, on the
other hand, we name methods as `Foo()` if they won't return `nullptr`.
`RangeBoundaryBase::Container()` may return `nullptr`. So, this name may cause
misleading of some developers. Let's rename it as `GetContainer()`.
This does not change anything for avoiding merge conflict with the other
landings.
Differential Revision: https://phabricator.services.mozilla.com/D236796
There are some callers of parent/offset version which computes offset before.
However, the offset may not be used. Therefore, the callers should use
`RangeBoundaryBase` version.
Additionally, if only one of the pairs is computed from `RangeBoundaryBase`,
such callers should use the `RangeBoundaryBase` version too because the offset
computation may be skipped. In this case, temporary `RangeBoundaryBase` should
be a `RawRangeBoundary` and whose `aRangeIsMutationObserver` should be set to
`RangeBoundaryIsMutationObserved::No` to avoid immediately to compute the child
node from `aOffset`. I think that this should be default to
`RangeBoundaryIsMutationObserved::No` in the future, but for now, we should just
make the users explicitly set it to `RangeBoundaryIsMutationObserved::No` for
avoiding regressions.
Differential Revision: https://phabricator.services.mozilla.com/D236793
`nsFrameSelection::GetLimiter()` is not `nullptr` only when it's an instance for
an independent selection of a text control. In the case, it's set to the editor
root anonymous `<div>` of the text control. Despite the name, this is already
optimized only for this purpose in `nsFrameSelection::NodeIsInLimiters()`.
Thus, we don't have any problems to make this clearer for the other developers
with renaming some parameter names.
`nsFrameSelection::GetAncestorLimiter()` is also always an `Element`. So,
we can change this to `Element` too.
Differential Revision: https://phabricator.services.mozilla.com/D235254
`AutoRangeArray` is created for making some handlers of the editor classes free
from `Selection` and `nsFrameSelection` while handling the edit actions.
However, the method still depends on `nsFrameSelection` instance since its
callees are instance methods of `nsFrameSelection`.
However, `EditContext` requires completely free methods to compute target
ranges of `beforeinput`. Therefore, we need to make it not depend on
`Selection` nor `nsFrameSelection`.
The common method, `nsFrameSelection::CreateRangeExtendedToSomewhere`, requires
`PresShell`, selection limiter which is set only when the selection is an
independent selection like in a selection for a text control, selection
ancestor limiter which is set only when an editing host has focus, caret
association hint to put caret to end of preceding line or start of following
line if selection range is collapsed at a line break and caret bidi level for
considering caret position around line break in bidi text. They are now stored
by `nsFrameSelection` and modified when selection range is changed in some
cases. Basically, the method is called without updating its ranges and if and
only if it's initialized with `Selection`. So, simply caching the
`nsFrameSelection`'s values solves the issues in the most cases, but this
patch makes `AutoRangeArray` adjust the value only when its `Collapse` is
called because `Selection` automatically updates it and we can compute the
value without `Selection` nor `nsFrameSelection`.
After applying this patch, `AutoRangeArray` has two meanings, one is the
instance is a proxy for `Selection`. The other is a container for a range to
call methods which take pointer or reference to it. To make this differences
checked at build time, this patch creates a new subclass of it, and renamed to
`AutoClonedRangeArray` to make it clearer that what are stored in the array.
Oddly, `AutoRangeArray(nsRange&)` constructor has not been cloned. Therefore,
I make it and its subclass version clone before storing into the array. Then,
one caller needs to change which range should be tracked.
Differential Revision: https://phabricator.services.mozilla.com/D232174
`nsFrameSelection::NormalSelection()` returns a `Selection&`, which eliminates the need for nullptr check at call sites.
This simplifies the code in some places and removes unnecessarily indented blocks.
Differential Revision: https://phabricator.services.mozilla.com/D230583
I wonder if this relates to shadow-crossing selection. I.e,
the default boundaries (nsRange.mStart, nsRange.mEnd) are collapsed,
but there's a CrossShadowBoundaryRange that makes this nsRange
still valid to many callers.
So adding this assertion to help diagnosing.
Differential Revision: https://phabricator.services.mozilla.com/D222864
Determining if a node is selected is a super-hot code path,
which at times introduces jank both in Reflow and Painting.
This is due to each node comparing its position to the range's start and end point,
which even happens several times (`nsINode::IsSelected()` and `Selection::LookupSelection()`).
In worst cases, this can lead to reflow which takes several minutes.
This patch introduces a cache which contains all fully selected nodes,
and lives throughout one `PresShell::DoReflow()` call.
Collecting all selected nodes of a selection is very fast.
The selected nodes are then stored in a hash set.
During reflow the check if a node is selected first checks the cache
if the node is fully selected, and otherwise goes through the existing
code to check if the node is partially selected.
Differential Revision: https://phabricator.services.mozilla.com/D217794
nsISelectionListener isn't sufficient because it only notifies that the selection has changed.
A11y needs to know specifically which ranges were added or removed.
Previously, we handled this specifically for spelling errors in mozInlineSpellChecker.
That code has been removed and replaced with a more general approach.
Since we now have these notifications, rather than using nsISelectionListener just to fire events, we now use these notifications for that as well.
This avoids the need to add additional nsISelectionListeners, which would get messy particularly for custom highlights where there can be an arbitrary number of selections at any given time.
Differential Revision: https://phabricator.services.mozilla.com/D217068
There are no callers from JS (looked at the selection region constant
usage in idl and those use nsISelectionController, not this).
If we were to provide this API in the future, it would probably use
ScrollIntoViewOptions or so instead (plus something extra perhaps).
I wanted to remove the weird WehreToScroll percentage impl, but actually
some C++ accessibility code still uses it.
Differential Revision: https://phabricator.services.mozilla.com/D216872
There are no callers from JS (looked at the selection region constant
usage in idl and those use nsISelectionController, not this).
If we were to provide this API in the future, it would probably use
ScrollIntoViewOptions or so instead (plus something extra perhaps).
I wanted to remove the weird WehreToScroll percentage impl, but actually
some C++ accessibility code still uses it.
Differential Revision: https://phabricator.services.mozilla.com/D216872
Also, in EventStateManager, convert `ComputeScrollTarget()` and
`ComputeScrollTargetAndMayAdjustWheelEvent()` to return `ScrollContainerFrame*`
so that we can drop more unnecessarily `do_QueryFrame`.
Due to removing `nsIScrollableFrame` forward declaration in DOM headers, we have
to add `nsIScrollableFrame` forward declaration temporarily in
nsMenuPopupFrame.h to make this patch compile, but we'll remove it once we
remove `nsIScrollableFrame` under layout/.
Differential Revision: https://phabricator.services.mozilla.com/D211496
