Граф коммитов

2 Коммитов

Автор SHA1 Сообщение Дата
Masayuki Nakano 51a4bc4fb8 Bug 1766355 - part 4: Make `HTMLEditor::MoveNodeWithTransaction` and `HTMLEditor::MoveNodeToEndWithTransaction` return `MoveNodeResult` r=m_kato
Differential Revision: https://phabricator.services.mozilla.com/D146400
2022-05-20 08:28:09 +00:00
Masayuki Nakano c5b2a589bd Bug 1766355 - part 1: Add `MoveNodeTransaction` to handle delete node and insert node in a transaction class instance r=m_kato
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
2022-05-20 08:28:08 +00:00