We usually need to move consecutive siblings to move a line to another
block or unwrap children of a container element or replacing a container
element (with preserving the children of the old container element).
So, we need to create `MoveNodeTransaction` per node, but the number of
that is too many. Therefore, we should coalesces some movements within
a transaction.
Moving consecutive siblings is the easiest way to do that because it
can manage the destinations of undo/redo for the all nodes which the
transaction moved.
Differential Revision: https://phabricator.services.mozilla.com/D259712
So, `Text` editor can access the `Text` node quickly and it's not needed to
be grabbed by a lot of transactions. Additionally, when we support keeping
`TextEditor` instance even if the text control is reflowed (bug 1922141,
bug 1339052 and bug 1620050), transactions need to work with new anonymous
nodes. Therefore, retrieving `Text` node of `TextEditor` each time does make
sense rather than storing the node.
Depends on D240419
Differential Revision: https://phabricator.services.mozilla.com/D240420
First, `EditorBase::CreateTransactionForDeleteSelection` returns an instance of
`EditAggregateTransaction`. It's a base class of `PlaceholderTransaction` and
`DeleteRangeTransaction` but it's also a concrete class. However, it's too
generic. Therefore, this patch creates `DeleteMultipleRangesTransaction` which
is a simple sub-class of it, and makes `EditAggregateTransaction` be an abstract
class. Then, add `AddChild` methods to each concrete class to restrict the
type of child transactions.
Next, `DeleteRangeTransaction` contains only `DeleteNodeTransaction` and
`DeleteTextTransaction`. Therefore, once they have a common base class,
we can check the type easier. Therefore, this patch also adds
`DeleteContentTransactionBase` and
`EditorBase::CreateTransactionForCollapsedRange` becomes clearer what it
returns.
With these changes, `DeleteRangeTransaction` obviously contains only
`DeleteContentTransactionBase`, `DeleteMultipleRangesTransaction` contains only
`DeleteRangeTransaction`, `DeleteNodeTransaction` and `DeleteTextTransaction`.
And they are guaranteed at build time (at least from outside the classes).
***
fix
Differential Revision: https://phabricator.services.mozilla.com/D169038
nsISupports.h includes nsISupportsBase.h, so it should be equivalent.
In the next patch, I'm changing things so that nsISupports is defined in
nsISupports.h instead of nsISupportsBase.h, and deleting the latter, so
this change will be needed anyways. I'm guessing people were using IWYU
or something like that.
Differential Revision: https://phabricator.services.mozilla.com/D159169
Creating both `DeleteNodeTransaction` and `InsertNodeTransaction` wastes
memory. They should be done in an instance instead.
Fortunately, no edit action listener checks whether the deleted node is still
in the composed document or not, etc. Therefore, we can simply notify them of
both deletion and insertion which were done in
`EditorBase::InsertNodeWithTransaction` and
`EditorBase::DeleteNodeWithTransaction`. Note that previously, the range
updater needs to ignore the notifications from them while the node is being
moved. However, it does not require anymore. Therefore, this patch makes it
stop locking, and that would fix minor problem in the case of legacy mutation
event listeners run another edit action.
On the other hand, this changes some edge cases handling of
`MoveNodeWithTransaction` which are detected by the WPT. According to the
previous result of applying this patch, `nsINode::InsertBefore` fails and that
leads some errors at updating the changed range. I guess that the cause is
that there is some bugs at updating insertion point after deleting the node from
the DOM tree around here:
https://searchfox.org/mozilla-central/rev/0ffae75b690219858e5a45a39f8759a8aee7b9a2/editor/libeditor/HTMLEditor.cpp#5058-5071
However, it's safely fixed by the new code which does not remove the node from
the DOM tree explicitly. So, I think that it's safe to accept this behavior
change for web apps in the wild.
Differential Revision: https://phabricator.services.mozilla.com/D146397
It's already disabled since 96 and now is late 97 cycle in the release channel,
but I've not gotten regression reports about this. Therefore, we should get
rid of it from the tree completely, then, we can make
`HTMLEditor::CreateAndInsertElementWithTransaction` greater for its callers.
Depends on D139717
Differential Revision: https://phabricator.services.mozilla.com/D139718
For consistency with the other things in editor module, it should be "nodes"
rather than "node" since 2 nodes are joined by it.
Differential Revision: https://phabricator.services.mozilla.com/D139715
Currently, when `HTMLEditor` replaces text in a text node, `HTMLEditor`
creates a set of `DeleteTextTransaction` and `InsertTextTransaction`.
However, this has bad impact for footprint and causes the callers messy.
This patch creates `ReplaceTextTransaction` instead and
`HTMLEditor::ReplaceTextWithTransaction()` as its wrapper. Unfortunately,
this becomes not calling `nsIEditActionListener::DidDeleteText()`, however,
this is not used by mozilla-central, comm-central nor BlueGriffon. IIRC,
it was not removed for some legacy addons of Thunderbird. Therefore, it
must be okay to remove it.
Differential Revision: https://phabricator.services.mozilla.com/D76078
In a lot of places in libeditor, we do nothing if given transaction is not
our edit transaction classes' instance. Therefore, it's better to have
casting virtual method in `nsITransaction` for performance because QI cost
may not be cheap.
Differential Revision: https://phabricator.services.mozilla.com/D71908
Although, we don't need factory methods for DeleteRangeTransaction,
EditAggregateTransaction nor PlaceholderTransaction, for consistency with the
other transaction classes, they should have factory methods for making easier
to write the code.
For not making the performance slow down, they should be inline methods.
MozReview-Commit-ID: 7jl5yZNFYmP
Sylvestre Ledru