Currently, `operator<<(std::ostram&, const nsINode&)` prints the path
of the node with some attribute information of each node. However, there
are some issues:
1. It's unclear if the reached root is a `DocumentFragment` or
`ShadowRoot` due to the same node name, `#document-fragment`.
2. Do not print the host's path.
3. Cannot print only in a specific node such as a `contenteditable`.
4. It's hard to consider which `Text` if a node has multiple `Text`
nodes.
5. No information about the assigned `<slot>`.
6. No information about `EditContext`.
This patch appends these information to each node. Additionally, adding
`format_as()` for avoiding to use `mozilla::ToString` for `fmt::format`
and `MOZ_LOG_FMT`.
Finally, to test the new data, this makes `Selection` and `SelectionAPI`
log use `MOZ_LOG_FMT`.
Differential Revision: https://phabricator.services.mozilla.com/D304964
Previously, `Compute*()` methods temporarily updated `Selection` for
emulating the corresponding `Handle*()` method behavior. However,
they have already been fixed as not using `Selection`. Therefore,
we can make
`AutoBlockElementsJoiner::ComputeRangeToDeleteAtOtherBlockBoundary` stop
updating `Selection` only for
initializing `AutoClonedSelectionRangeArray` instance.
Differential Revision: https://phabricator.services.mozilla.com/D301693
The current mozilla::ScrollAxis struct in PresShellForwards.h isn't a simple
axis enum. It carries information about where to scroll to along a specific
axis, and under what conditions that should happen. So 'ScrollAxis' isn't the
best name.
Now we're introducing WebIDL 'ScrollAxis' in bug 1350457:
https://drafts.csswg.org/scroll-animations-1/#scrolltimeline-interface
The extensive use of PresShellForwards.h's ScrollAxis in DOM code makes it
conflict with this new DOM enum. Rather than try to fix this through lots of
explitic namespacing, this patch renames PresShellForwards.h's ScrollAxis.
Differential Revision: https://phabricator.services.mozilla.com/D293485
This reverts commit 88008cd8ca.
Revert "Bug 2012637 - part 8: Make `nsContentUtils::ComparePoints` handle `TreeKind::Flat` and `TreeKind::FlatForSelection` correctly r=smaug,dom-core"
This reverts commit 73e6f6587b.
Revert "Bug 2012637 - part 7: Make `RangeUtils::CompareNodeToRangeBoundaries()` use `nsContentUtils::ComparePoints` with valid point in the tree r=smaug"
This reverts commit 6985d5e80f.
Revert "Bug 2012637 - part 6: Make `nsRange::CutContents()` convert the range boundaries to the ones in the DOM before comparing r=smaug"
This reverts commit 73b585af3d.
Revert "Bug 2012637 - part 5: Delete the default template parameter of `nsContentUtils::ComparePoints` and relatives r=smaug,dom-core"
This reverts commit 1a7f24e5b5.
Revert "Bug 2012637 - part 4: Make `nsContentUtils` use `nsIContent` for taking a child node as a parameter r=smaug"
This reverts commit a6ea8d6824.
Revert "Bug 2012637 - part 3: Add template `nsINode` API which can switch to call API from `TreeKind` r=smaug,dom-core,webidl"
This reverts commit a4211e9df0.
Revert "Bug 2012637 - part 2: Add `TreeKind::FlatForSelection` and change the template parameter of `ChildIteratorBase` to `TreeKind` r=smaug,dom-core"
This reverts commit 0241749ee7.
Revert "Bug 2012637 - part 1: Make `ChildIterBase` template class to re-implement `FlattenedChildIterator` for DOM, Flat and FlatForSelection TreeKind r=smaug,dom-core,layout-reviewers,emilio"
This reverts commit 9e71cb77fb.
I believe that the method does wrong things. The method's parameter
should be a boundary in the non-flattened tree. Additionally, it
needs to compare the anchor-focus range in the non-flattened tree
because the DOM API does not support cross shadow range.
In other words, the method should work with range boundaries in the
non-flattened tree and the result may cross the shadow DOM boundaries
if the boundaries in the flattened tree are in different shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D282107
They compare the given range boundary and given range start/end
boundary. At this time, it creates `ConstRawRangeBoundary` instance
with the container and the offset of the range boundary whose `TreeKind`
may be `FlatForSelection`. In this case, the offset may be invalid in
the shadow including DOM. Therefore, they need to convert the
boundaries to the points for the comparing `TreeKind`.
Oddly, this causes hitting the assertion in
`RangeBoundaryBase::AsRangeBoundaryInFlatTree()` because the range
boundary has wrong offset and do not have the `Ref()`. According to
the stack trace, the wrong offset comes from
`nsTextFrame::GetSelectionDetails()` during reflow. Therefore, I don't
want to investigate the layout code's bug in this bug. Thus, this patch
changes the `MOZ_ASSERT` to `NS_ASSERTION` instead.
Differential Revision: https://phabricator.services.mozilla.com/D281313
It may call `nsContentUtils::ComparePoints_AllowNegativeOffsets()` and
`nsContentUtils::ComparePointsWithIndices()` within points in different
kind of tree. Therefore, it should use `ConstRawRangeBoundary` and
convert the points to the one in the expected tree.
Differential Revision: https://phabricator.services.mozilla.com/D281310
They accept any kind of points even if it does not match with the
template parameter's `TreeKind` because the caller wants to check the
relation in different kind of tree. Therefore, any callers need to
consider the `TreeKind` more carefully and clarify the `TreeKind` makes
developers easier to find a bug.
Differential Revision: https://phabricator.services.mozilla.com/D281308
This add `TreeKind::FlatForSelection` which should ignore the UA shadow
trees which are created in `<details>`, `<video>`, SVG `<use>`, etc
because their children are not selectable or slotted and reordered by
the shadow tree so that `Selection` and `AbstractRange` need to work
with their children in the non-flattened tree.
This patch does not change the behavior. It'll be done by a following
patch.
Differential Revision: https://phabricator.services.mozilla.com/D281304
`FlattenedChildIterator` is a non-template class and work only for the
flattened tree (i.e., in the `TreeKind::Flat` mode).
To centralize the implementation to access children from a parent node
in the various kinds of tree except `ShadowIncludingDOM`, this patch
makes it a template class and support the simple DOM (for
`TreeKind::DOM`), the flattened tree (for`TreeKind::Flat`) and also the
flattened tree for selection whose `TreeKind` will be added by the next
patch.
The reason why this patch does not support
`TreeKind::ShadowIncludingDOM` is, it is not clear that which children
should be handled when the parent is a shadow host, i.e., whether the
children of the host or the `ShadowRoot`. Therefore, the caller should
use `ShadowRoot` if the users want to list up the the children from a
host. Then, the code is really clear about what it does.
Differential Revision: https://phabricator.services.mozilla.com/D281303
There's still a ton of things that can be cleaned up after this, but
this setup is nicer.
For now, editor keeps getting set-up / torn down on BindToFrame. Seems
all that could be untangled, but step by step.
The preview stuff and placeholder can just be created on demand now,
rather than requiring frame reconstruction.
Also, nsSearchControlFrame and co no longer do anything of interest, so
move the still relevant bits elsewhere and remove them.
test_bug1248459.html is removed because it messes with the editor
selection using SpecialPowers, in a way such that it crosses shadow
boundaries, and messes up the selected state triggering debug asserts.
test_focus_docnav.xhtml now triggers a different code-path because of
the shadow root (rather than the frame tree traversal). Keep it working
for now by replacing it with something that isn't a shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D282953
Currently, the method may return unset boundary. However, we need to
map a DOM tree point to a flat tree point.
The wrong point of current implementation is, the method respect the
container and offset. However, that may be wrong if the pointing child
node is moved into a `<slot>` or a `ShadowRoot`. Instead, this patch
computes proper parent from pointing child node if there is.
(I think there should be `nsINode::ComputeFlatTreeIndexOfForSelection`
or something, but I'd like to put off doing that later because it'd
affect to wider scope of our code.)
Differential Revision: https://phabricator.services.mozilla.com/D279308
If it points to a child node, it may be created for an `nsRange` and
even for creating a temporary instance with it, it is for validating
the point. Therefore, if there are factory methods which return unset
instance when the given point is invalid, the constructors can assert
valid point.
However, `StaticRange` can be created with invalid points. Therefore,
they should keep allowing to be initialized with an invalid point when
it'll point to an offset.
Note that this does NOT mean `RangeBoundaryBase` won't have invalid
point because it can be modified intentionally or mutations may
invalidate the point but nobody may not update the instance.
And also not that this accepts new regressions of `<use>` cases in the
WPT. This will be fixed in bug 2010730.
Differential Revision: https://phabricator.services.mozilla.com/D279307
`RangeBoundaryBase` allows to be initialized with invalid data for
allowing the users to use it as a validator. However, this is bad,
and now it supports 2 tree kinds. So, the users need to be familiar
with the relation of a child node and its parent and its offset when
they use `TreeKind::Flat`. For making it easier to use, this patch
adds some new factory methods which automatically computes proper
parent/offset for a node with the `TreeKind`.
Differential Revision: https://phabricator.services.mozilla.com/D279306
This reverts commit 5728aae19d.
Revert "Bug 2009323 - part 1: Make `RangeBoundaryBase` have some factory methods which take only a child node r=jjaschke,dom-core"
This reverts commit 41c5bea4d5.
Currently, the method may return unset boundary. However, we need to
map a DOM tree point to a flat tree point.
The wrong point of current implementation is, the method respect the
container and offset. However, that may be wrong if the pointing child
node is moved into a `<slot>` or a `ShadowRoot`. Instead, this patch
computes proper parent from pointing child node if there is.
(I think there should be `nsINode::ComputeFlatTreeIndexOfForSelection`
or something, but I'd like to put off doing that later because it'd
affect to wider scope of our code.)
Differential Revision: https://phabricator.services.mozilla.com/D279308
If it points to a child node, it may be created for an `nsRange` and
even for creating a temporary instance with it, it is for validating
the point. Therefore, if there are factory methods which return unset
instance when the given point is invalid, the constructors can assert
valid point.
However, `StaticRange` can be created with invalid points. Therefore,
they should keep allowing to be initialized with an invalid point when
it'll point to an offset.
Note that this does NOT mean `RangeBoundaryBase` won't have invalid
point because it can be modified intentionally or mutations may
invalidate the point but nobody may not update the instance.
And also not that this accepts new regressions of `<use>` cases in the
WPT. This will be fixed in bug 2010730.
Differential Revision: https://phabricator.services.mozilla.com/D279307
`RangeBoundaryBase` allows to be initialized with invalid data for
allowing the users to use it as a validator. However, this is bad,
and now it supports 2 tree kinds. So, the users need to be familiar
with the relation of a child node and its parent and its offset when
they use `TreeKind::Flat`. For making it easier to use, this patch
adds some new factory methods which automatically computes proper
parent/offset for a node with the `TreeKind`.
Differential Revision: https://phabricator.services.mozilla.com/D279306
I'm often confused at `RangeBoundaryIsMutationObserved` and
`RangeBoundaryBase::mIsMutationObserved` due to their names. They are
default to `Yes` or `true`. However, `RangeBoundaryBase` may be used for
temporary objects too without mutation observer. Therefore, they may
lie.
On the other hand, the most usage of
`RangeBoundaryBase::mIsMutationObserved` is, to check whether the
instance points to child node or offset. So, I think they can be changed
to `enum class RangeBoundaryPointsTo { Offset, ChildNode }` and
`mPointingToChildNode`.
Differential Revision: https://phabricator.services.mozilla.com/D279300
This patch does small refactorings like modernizing loops.
In addition, the `StyledRange` struct is moved into the `mozilla::dom`
namespace.
There are no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D279475
The `StyledRange`s in `Selection` need to be stored sorted by start
position in the DOM. At the same time, the style data needs to be
queried during paint, using a range pointer as key.
Before this patch, the data was stored in an `nsTArray`, which led to
linear lookup times during paint. This could lead to noticeable jank
in situations with many ranges (e.g. CSS Highlight API).
Since the data is key-value-ish, the data structure is changed
to use a sorted array of `AbstractRange`s in addition to a lookup table
for the `TextRangeStyle`s.
This patch tries to keep refactorings to a minimum
and should not change any behavior.
Differential Revision: https://phabricator.services.mozilla.com/D279474
Additionally, this adds some shortcut operators to `FrameAndOffset`.
Therefore, some users of derived structs of `FrameAndOffset` become
simpler.
Differential Revision: https://phabricator.services.mozilla.com/D273716
After the previous patches, nsViewManager is basically a backpointer to
its pres shell.
Remove it and just make PresShell manage the root view directly. After
this is done, we can decide what to do about nsView (which is itself
little more than a widget listener that forwards to pres shell right
now).
This technically starts listening to mParentWidget slightly later (on
pres shell creation), but I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D272890
The other browsers do not support multiple selection ranges. Therefore,
they never split selection ranges to exclude non-selectable nodes.
To align the behavior, we should do so. However, to keep current
look of `Selection` which is similar to Chrome's behavior, we should
make the selection painters ignore normal selections if their content
is not selectable.
Note that this patch allows painting selected text when there are some
IME selections even if `user-select` is `none` because the normal
selection is also a part of IME selections. Although our widget
currently do not use non-collapsed normal selection during a
composition, it may be changed to support new IME in the future.
Differential Revision: https://phabricator.services.mozilla.com/D272187
This patch removes the term "text fragment" from `nsTextFrame`,
and replaces it with `character data buffer`. There are no changes in logic.
Differential Revision: https://phabricator.services.mozilla.com/D259936
This patch updates all occurrences of the type `nsTextFragment` into its new name, `mozilla::dom::CharacterDataBuffer`.
It also updates the includes, including sorting.
Differential Revision: https://phabricator.services.mozilla.com/D259867
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
https://phabricator.services.mozilla.com/D251609 introduces a new type
to `RangeBoundary` so that it has different behaviours for
`TreeKind::DOM` and `TreeKind::Flat`. There was a concern about
mix-using the boundaries that had different types, it would be
error-prone.
The idea to address that concern is we always keep nsRange::mStart
and nsRange::mEnd to use `TreeKind::DOM`, and make
CrossShadowBoundaryRange to always use `TreeKind::Flat`. This also means
that we need to create CrossShadowBoundaryRange more often.
Differential Revision: https://phabricator.services.mozilla.com/D254081
Cosmin Sabou