Optimize `HTMLEditor::MoveNodeTransaction` and stop touching `Selection` directly
Categories
(Core :: DOM: Editor, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox102 | --- | fixed |
People
(Reporter: masayuki, Assigned: masayuki)
References
(Blocks 1 open bug)
Details
Attachments
(9 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
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.
Depends on D146365
Assignee | ||
Comment 2•3 years ago
|
||
Depends on D146397
Assignee | ||
Comment 3•3 years ago
|
||
Depends on D146398
Assignee | ||
Comment 4•3 years ago
|
||
Depends on D146399
Assignee | ||
Comment 5•3 years ago
|
||
Unfortunately, they call each other. Therefore, this patch updates these 2
methods once.
Depends on D146400
Assignee | ||
Comment 6•3 years ago
|
||
Depends on D146401
Assignee | ||
Comment 7•3 years ago
|
||
Depends on D146402
Assignee | ||
Comment 8•3 years ago
|
||
Depends on D146403
Assignee | ||
Comment 9•3 years ago
|
||
Depends on D146404
Comment 10•3 years ago
|
||
Comment 11•3 years ago
|
||
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
Comment 14•3 years ago
|
||
Comment 15•3 years ago
|
||
Comment 16•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0a70ca805cf3
https://hg.mozilla.org/mozilla-central/rev/95f6971b0c8b
https://hg.mozilla.org/mozilla-central/rev/18cc1b0df88f
https://hg.mozilla.org/mozilla-central/rev/f018103a7c22
https://hg.mozilla.org/mozilla-central/rev/e4d0bdba5d61
https://hg.mozilla.org/mozilla-central/rev/3909db95d934
https://hg.mozilla.org/mozilla-central/rev/cf8266e8b933
https://hg.mozilla.org/mozilla-central/rev/d817ed26cad0
https://hg.mozilla.org/mozilla-central/rev/a052a54eb167
Description
•