Clean up around `DeleteSelectionWithTransaction()`
Categories
(Core :: DOM: Editor, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: masayuki, Assigned: masayuki)
References
(Regressed 1 open bug)
Details
Attachments
(5 files)
I'd like to land some patches to clean up around DeleteSelectionWithTransaction()
which are written for bug 1618457.
Assignee | ||
Comment 1•5 years ago
|
||
DeleteSelection*()
are members of TextEditor
, but they are also used by
HTMLEditor
. Therefore, they and pref cache members for them should be
in EditorBase
too.
Depends on D71911
Assignee | ||
Comment 2•5 years ago
|
||
Depends on D72290
Assignee | ||
Comment 3•5 years ago
|
||
The parameter is used only by EditorBase::CreateTxnForDeleteRange()
to
extend collapsed range, but it accepts only nsIEditor::eNext
and
nsIEditor::ePrevious
. Therefore, using nsIEditor::EDirection
does not
make sense. Instead, they should use new enum class
,
HowToHandleCollapsedRange
.
Depends on D72291
Assignee | ||
Comment 4•5 years ago
|
||
HTMLEditor::DeleteSelectionWithTransaction()
calls EditorBase
's overridden
method and handles nsIEditor::eStrip
case. Therefore, we can rename it with
stop calling the EditorBase::DeleteSelectionWithTransaction()
, and make it
called by EditorBase::DeleteSelectionWithTransaction()
only when it's
necessary.
Additionally, we can make all internal method callers of editor classes always
set nsIEditor::eNoStrip
if the instance is TextEditor
. This must make
the code easier to understand.
Depends on D72292
Assignee | ||
Comment 5•5 years ago
|
||
The out params mean the last collapsed selection range's result (although,
the meaning is odd and offset and length are not overwritten when there is
another collapsed range and it causes DeleteNodeTransaction
). Additionally,
when and only when DeleteNodeTransaction
and DeleteTextTransaction
are
added to the EditAggregationTransaction
created by
CreateTransactionForSelection()
. Therefore, same result can be looked for
from its only caller, DeleteSelectionWithTransaction()
.
Note that this makes the method slower if there are too many selection ranges,
but such case must be rare because:
- We can assume that users rarely use multiple selection ranges for removing
multiple ranges of content except table. - Multiple selection is supported only by Gecko. Therefore, web apps must
not use multiple selection for this purpose.
So, it must be okay to use this slower approach for making the methods simpler.
If it'd become damage to some benchmarks, let's create faster access to get
transaction type.
Depends on D72293
Comment 7•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9f234ed7095b
https://hg.mozilla.org/mozilla-central/rev/2b18958a59bb
https://hg.mozilla.org/mozilla-central/rev/06cd5b2202f6
https://hg.mozilla.org/mozilla-central/rev/0433ceeed6a8
https://hg.mozilla.org/mozilla-central/rev/f6310e0f0afd
Assignee | ||
Updated•5 years ago
|
Description
•