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
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
Before this patch, the `AutoFrameSelectionBatcher` helper class would always call `NotifySelectionListeners()` for `SelectionType::eNormal`, even if the selection may have originated from Custom Highlight.
This patch moves the information that a change has occurred during batching from `nsFrameSelection` into the `Selection` instance, thus keeping the information per instance instead of globally.
When batching ends, `Selection::NotifySelectionListeners()` is called for all `Selection` instances depending on the flag.
Additionally, `Selection::NotifySelectionListeners()` is updated so that some Listeners (AutoCopyListener, SelectionChangeEvent, AccessibleCaret) are only notified for `SelectionType::eNormal`.
Differential Revision: https://phabricator.services.mozilla.com/D210130
The current code doesn't make a lot of sense:
* We should do no changes (certainly not move focus and co) when we're
batching, since we'll reenter.
* We forgot to pop the change reasons and schedule content visibility
updates when there were no listeners. I think this is a no-op change
tho since nowadays we ~always create an accessible caret, even on
desktop...
Try to improve it.
Differential Revision: https://phabricator.services.mozilla.com/D210051
This new cache implementation keeps the last N node/index combos in a stack-allocated array, which will be queried before calling nsINode::ComputeIndexOf().
Differential Revision: https://phabricator.services.mozilla.com/D203900
This new cache implementation keeps the last N node/index combos in a stack-allocated array, which will be queried before calling nsINode::ComputeIndexOf().
Differential Revision: https://phabricator.services.mozilla.com/D203900
This new cache implementation keeps the last N node/index combos in a stack-allocated array, which will be queried before calling nsINode::ComputeIndexOf().
Differential Revision: https://phabricator.services.mozilla.com/D203900
This new cache implementation keeps the last N node/index combos in a stack-allocated array, which will be queried before calling nsINode::ComputeIndexOf().
Differential Revision: https://phabricator.services.mozilla.com/D203900
These loops may run script.
In `HyperTextAccessible`, it calls
`RemoveRangeAndUnselectFramesAndNotifyListeners`. So, chrome script which is not
directly related to this module may run in each call. I think that using
`RemoveAllRanges` is better for here. Before bug 1735446, this loop tried
to keep first range, but accidentally, I changed this loop delete all ranges.
However, `SetSelectionBoundsAt` will add a range if it's required and there is
no bug reports. Therefore, I think keep the new behavior is better.
In `nsRange::DeleteFromDocument`, the loop may run mutation events too.
Therefore, it needs to store all ranges first. Then, the preceding patch
changes the behavior here if a selection range is moved to different root.
Previously, it was deleted, but now, they are not touched.
Depends on D200606
Differential Revision: https://phabricator.services.mozilla.com/D200607
Ranges stored in Selection::StyledRanges are expected to be sorted by their start point.
In Bug 1872535 a range reordering was introduced which makes sure that static ranges are at the right spot after a DOM mutation has happened.
Reordering is necessary in two conditions:
- The document generation has changed (=There are changes to the DOM tree)
- A selection has changed (which would call NotfySelectionListeners())
However, when a range is added, it is not necessary to reorder, since the AddRange...() method inserts the new range at the correct spot (and reorders beforehand if necessary).
Differential Revision: https://phabricator.services.mozilla.com/D200592
Ranges inside of a `Selection` are expected to be sorted by their start point by the painting algorithms. Also, `StaticRange`s, which previously were not part of `Selection`, need to be considered for painting based on their `IsValid()` status.
This is now added by introducing a second array for invalid static ranges and an additional re-ordering method which needs to be called before paint that moves ranges in between.
A potential change in range endpoints can be determined by observing the `Document`s generation and by adding a flag that's set to true in `Selection::NotifySelectionObservers()`.
Differential Revision: https://phabricator.services.mozilla.com/D198943
The methods are in `nsCaret`, `nsFrameSelection` and `dom::Selection`. That
makes harder to read, and they are called each other, so, they are reused for
different purpose. Therefore, it must be better to move them into a new class.
Then, the name differences may become more unclear. If you think so, feel free
to request renaming some methods of them.
Differential Revision: https://phabricator.services.mozilla.com/D197288
A caller of it should be independent from `nsFrameSelection` instance.
Therefore, I'd like to separate it to static method part and instance method
part.
Differential Revision: https://phabricator.services.mozilla.com/D197287
Its name sounds a getter, but it updates the caret association hint of
`nsFrameSelection`, but at least, one of its callers,
`nsFrameSelection::PeekOffsetForCaretMove` shouldn't update it because it
just scans the previous or next position for caret.
Then, `Selection::GetPrimaryFrameForFocusNode` can be implemented with a
new static method which is useful for `PeekOffsetForCaretMove` when it becomes
a static method.
Differential Revision: https://phabricator.services.mozilla.com/D197286
Oddly, it updates `nsFrameSelection` instance and some root callers may depend
on that. Therefore, this patch keep updating `nsFrameSelection` in the callers.
Differential Revision: https://phabricator.services.mozilla.com/D197284
When pressing `ArrowLeft` key at:
```
<p>abc</p><p><span contenteditable=false>def</span>{}<br></p>
```
, caret is moved into the non-editable text because
`nsCaret::GetCaretFrameForNodeOffset` looks for a preceding text node from
the `BRFrame`. This is required if the preceding text node ends with a
collapsible white-space but followed by a `<br>` because the text frame
should not contain the white-space rect and `BRFrame` frame should be next
to it, i.e., the white-space looks like a overflown content.
So, for rendering a caret, the method needs to return non-editable text frame
even in the case, but for considering new caret position in the DOM tree, it
should not return non-editable text frame.
Therefore, this patch adds a param to `nsCaret::GetCaretFrameForNodeOffset()`
which forcibly return editable content frame or not and makes
`Selection::GetPrimaryOrCaretFrameForNodeOffset` call it with the new option
because its callers are the handler of caret navigation.
Differential Revision: https://phabricator.services.mozilla.com/D196259
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
This function had some code that we hadn't yet updated to support vertical
writing modes. This patch makes it more generic so that it can properly handle
vertical-writing-mode text nodes (so that we can e.g. properly keep the caret
scrolled into view, in a vertical-writing-mode textfield).
I'm just focusing on vertical vs. horizontal generification for now. I'm not
entirely sure if it makes sense to make it even-more-generic-still to support
reversed-inline-direction writing modes as well. I wasn't able to trigger any
issues with those in some brief testing, so I think this patch is sufficient
as-is, but I left a TODO(dholbert) code-comment to call out that ambiguity
that's still present in the code.
Differential Revision: https://phabricator.services.mozilla.com/D187160
This patch doesn't change behavior. It's just laying the groundwork for the
next patch which adds vertical-writing-mode support.
(This patch adds some documentation in terms of logical axes, though, which
will become accurate as of the next patch in this series.)
Differential Revision: https://phabricator.services.mozilla.com/D187161
This function had some code that we hadn't yet updated to support vertical
writing modes. This patch makes it more generic so that it can properly handle
vertical-writing-mode text nodes (so that we can e.g. properly keep the caret
scrolled into view, in a vertical-writing-mode textfield).
I'm just focusing on vertical vs. horizontal generification for now. I'm not
entirely sure if it makes sense to make it even-more-generic-still to support
reversed-inline-direction writing modes as well. I wasn't able to trigger any
issues with those in some brief testing, so I think this patch is sufficient
as-is, but I left a TODO(dholbert) code-comment to call out that ambiguity
that's still present in the code.
Differential Revision: https://phabricator.services.mozilla.com/D187160
This patch doesn't change behavior. It's just laying the groundwork for the
next patch which adds vertical-writing-mode support.
(This patch adds some documentation in terms of logical axes, though, which
will become accurate as of the next patch in this series.)
Differential Revision: https://phabricator.services.mozilla.com/D187161
It always set to "start of next line" when new range was added. However,
after bug 1815802, it does nothing when adding range is one of its ranges.
Therefore, if interline position is set to "end of line" by our internal
code, like editor, `getSelection().addRange(getSelection().getRangeAt(0))`
keeps the last interline position.
Differential Revision: https://phabricator.services.mozilla.com/D182300
