They at most twice updates the `Selection` right now. We can make them update
`Selection` once. And this patch makes the scope of `AutoRangeArray` clearer.
Differential Revision: https://phabricator.services.mozilla.com/D149087
Although they update the DOM tree with transactions, but for making `HTMLEditor`
smaller, and the following patches makes the related code simpler, we need to
move them into `AutoRangeArray`.
Differential Revision: https://phabricator.services.mozilla.com/D149084
`AutoRangeArran` uses `OwningNonNull`. So making the following patch simpler
and smaller, all places should use array of `OwningNonNull<nsRange>` instead of
`RefPtr<nsRange>`.
Differential Revision: https://phabricator.services.mozilla.com/D149076
This must make you feel odd. However, this is a separate patch for making easier
to review the following patches. This will be a private member of
`AutoRangeArray`.
Differential Revision: https://phabricator.services.mozilla.com/D149074
It's used only by `HTMLEditor::MoveOneHardLineContentsWithTransaction` and
it just calls 2 methods with some simple additional error handlings.
I'd like to make `SplitInlinesAndCollectEditTargetNodes` work with
`AutoRangeArray`. Therefore, I'd like to do this for avoiding to use
`AutoRangeArray` in `HTMLEditor.h`.
Differential Revision: https://phabricator.services.mozilla.com/D149070
Its callers check `EditorBase::Destroyed()` with at least adding 4 lines, and
some callers do not check this important state. So, we should make it check
`Destroyed()` at last and omit the additional error check in the caller sites.
Note that it's a virtual method, but `HTMLEditor` checks whether it's a
removable node or not. So, we should can merge it into `EditorBase`. This
patch does it too.
Differential Revision: https://phabricator.services.mozilla.com/D148084
In the testcase, editing host is removed when first node removing, but
`HTMLEditor::Destroyed()` still returns `false`. So, ideally, we should add
a check of editing host validity in `Destroyed()`, but for now, we should make
the method check whether the handling range is still editable after running
each transaction.
Depends on D147723
Differential Revision: https://phabricator.services.mozilla.com/D147724
The reported testcase causes an incompatible behavior with the other browsers,
that is, `selectAll` command without focus in document whose body ends with
editable nodes selects the nodes in the selection root for the focused node (end
of the range in the normal direction). Therefore, `HTMLEditor` handles deletion
in odd state (without focus handling). So the root cause is a bug in selection,
but this bug as of the editor module should avoid the try of joining nodes which
are moved by a DOM mutation event listener at the initial deletion.
Differential Revision: https://phabricator.services.mozilla.com/D147623
It's currently computes the corresponding editing host from the focus node of
`Selection` with climbing up the DOM tree. So, it does not just return a stored
element. Therefore, some callers use it multiple times. For avoiding it, we
should rename it to explain that it computes the editing host.
Note that I think that we should make it takes a node to compute editing host
without `Selection` for solving the case of no selection ranges. Therefore,
I don't like to include more information into the name.
Differential Revision: https://phabricator.services.mozilla.com/D147504
The implicit copy constructors and `operator=` makes it harder to realize
that implicit conversion wastes the runtime cost. Therefore, this patch
replaces them with a template method to convert the `EditorDOMPointBase` type.
Differential Revision: https://phabricator.services.mozilla.com/D143878
Some of them were `HTMLEditor` so that we need to fix it to `EditorBase`, and
also this patch fixes `NS_ERROR_EDITOR_DESTROYED` handling around them.
Differential Revision: https://phabricator.services.mozilla.com/D143815
First, move methods of `HTMLEditor` which collapse `Selection` to `EditorBase`.
Then, make editor stop accessing `Selection::CollapseInLimiter` directly.
Differential Revision: https://phabricator.services.mozilla.com/D143814
It's hard to remember what the `bool` value of them means. Therefore, there
are a lot of comment around the API users to explain what they do. For making
it clearer and reducing the risk of specifying opposite value, they should work
with an `enum class`.
Differential Revision: https://phabricator.services.mozilla.com/D143812
This patch renames it to `HandleInsertParagraphInMailCiteElement` to explain
what it does clearer. And make it takes most-distant ancestor mail-cite
element to avoid the situation that it does nothing.
Then, this is rewritten to just return new caret position where is new
`<br>` element which is inserted at the split point.
Then, only the last block is changed to refer the split node result to
avoid deleting same node in the case of new split direction.
Differential Revision: https://phabricator.services.mozilla.com/D142415
At initializing new element which has not been connected, undo transactions
are not necessary because just removing the new element gets same result for
users. Therefore, they should be able to work without transactions.
Differential Revision: https://phabricator.services.mozilla.com/D140468
The method caches a DOM point, but it is not tracked correctly.
This patch adds some validations into it and one of its callee,
`HTMLEditor::MoveOneHardLineContents`. Additionally, making
`EditorDOMPointBase::Offset` avoid accessing `Maybe`'s storage when it's
`Nothing` in release builds as the last resort.
Differential Revision: https://phabricator.services.mozilla.com/D136994
Due to a Selection API's bug, `Selection::Modify` may move selection into
native anonymous subtree. Although it should be fixed in the side, but
`HTMLEditor` should make range boundaries climb up to outside native anonymous
subtrees.
Depends on D137526
Differential Revision: https://phabricator.services.mozilla.com/D137527
Those methods use `RangeBoundary` or `RangeBoundaryBase`, and it makes reading
the code harder because of poor API comparing from `EditorDOMPointBase`, and
anyway they are converted to `EditorDOMPointBase`.
Therefore, they should take `EditorDOMPointBase` or `EditorDOMRangeBase`
instead.
Differential Revision: https://phabricator.services.mozilla.com/D137526
`HTMLEditor` assumes that inline elements cannot have block elements. However,
it's not so if it's created by DOM APIs like `Node.appendChild` or making a
custom element an editing host.
Therefore, it's not unexpected case that only start or end of a range does not
have a block ancestor element. So this patch makes `AutoBlockElementsJoiner`
not stop handling the deletion in the case.
Differential Revision: https://phabricator.services.mozilla.com/D136698
This patch implements `JoinNodesResult` class which callers of
`JoinNodesWithTransaction()` can access removed node, existing (joined) node and
joined point with logical named accessors, and makes
`JoinNodesWithTransaction()` return it.
Then, the callers don't need to change at fixing bug 1735608.
Differential Revision: https://phabricator.services.mozilla.com/D132120
Now, it does not notify nobody before joining the nodes. Therefore, it can
return error immediately if it fails to create a transaction to join the given
nodes.
Additionally, this patch makes it return `NS_ERROR_EDITOR_DESTROYED` if the
editor is destroyed while it handles to join nodes. Therefore, we can get rid
of the check by the callers.
Differential Revision: https://phabricator.services.mozilla.com/D130349
Now, it does not notify nobody before joining the nodes. Therefore, it can
return error immediately if it fails to create a transaction to join the given
nodes.
Additionally, this patch makes it return `NS_ERROR_EDITOR_DESTROYED` if the
editor is destroyed while it handles to join nodes. Therefore, we can get rid
of the check by the callers.
Differential Revision: https://phabricator.services.mozilla.com/D130349
And this renames the method to `ExtendOrShrinkRangeToDelete` for alining to
new behavior changed by the following patch.
Depends on D125028
Differential Revision: https://phabricator.services.mozilla.com/D125029
If caret is put at preformatted linefeed, we need to handle adjacent
collapsible white-spaces too if the style is `white-space: pre-line`.
Therefore, this patch makes the delete handler aware of the case only
linefeed characters are preformatted and `AutoDeleteRangesHandler` call it
when caret is around a preformatted line break.
Differential Revision: https://phabricator.services.mozilla.com/D124559
`WSRunScanner` is designed for scanning editable nodes, but
`IsVisibleTextNode()` should not check editable state. Therefore, it should
check it without `WSRunScanner` like `IsVisibleBRElement()`.
Differential Revision: https://phabricator.services.mozilla.com/D124554
The method may be used for checking a `<br>` element visibility in non-editable
content too. Therefore, using `WSRunScanner` which is designed for scanning
editable content hits assertions.
The visibility of `<br>` element is considered only with the following
visible thing. If it's followed only by another or current block boundary,
the `<br>` element is invisible. But otherwise, it's visible. So, it needs
to scan following contents to look for first visible thing until reaching
a block boundary. And it does not need to check its previous content.
Differential Revision: https://phabricator.services.mozilla.com/D123876
Currently, it uses "normal text" and "normal white-spaces" for naming
`enum class` members and their accessors. However, this is unclear what
does the normal mean since the word depends on context.
Therefore, this patch replaces the former with "non-collapsible characters" and
the latter is "collapsible white-spaces".
Differential Revision: https://phabricator.services.mozilla.com/D123872
On Thunderbird, we still have a bug to delete `<html>` and `<body>` elements
(bug 1727201). However, it's hard to know where deletes the unexpected elements
from warning messages in the log. Additionally, it's really serious bug
because editor and layout code rely on the basic structure of HTML document.
Therefore, we should block the worst scenario before deleting such nodes.
Differential Revision: https://phabricator.services.mozilla.com/D123418
The new editor utility method does not stop scanning editable elements even if
it reaches the document root nor the (primary) `<body>` element. Of course,
they should stop there if scanning editable block. And
`ScanEmptyBlockInclusiveAncestor()` shouldn't store the removable empty block
element to them.
Differential Revision: https://phabricator.services.mozilla.com/D123316
Additionally, the given content may be in a nested editing host. Then, this
method may delete a nested-block editing host if it's empty. Therefore,
this patch get rid of `aEditingHost` and check same thing with
`HTMLEditUtils::IsRemovableFromParentNode()`.
Depends on D123066
Differential Revision: https://phabricator.services.mozilla.com/D123067
I have no idea how to test this, but I believe that checking non-editable
block element must be correct here because it checks whether the block is
empty or not for merging lines.
Depends on D123029
Differential Revision: https://phabricator.services.mozilla.com/D123066
