Patch originally developed on bug 1458921 but needs to land with the WR update.
MozReview-Commit-ID: 82BYyNWBAfn
--HG--
extra : rebase_source : e6bca2f446c019fd41a37c2c28db73bbe1cfc216
HTMLEditor has 2 type of public methods. One is rue-public methods. I.e.,
they should be able to be called by anybody. E.g., command handlers, event
listeners, or JS via nsIEditor interface. The other is semi-public methods.
They are not called by the above examples but called by other classes which
are helper classes to handle edit actions. E.g., TextEditRules, HTMLEditRules,
HTMLEditUtils, CSSEditUtils and Transaction classes.
When we will implement InputEvent.inputType, we need to create new stack
class and create its instance at every true-public methods to manage current
inputType (like TextEditRules::AutoSafeEditorData). Therefore, it should not
happen that new code starts to call semi-public methods without the new
stack class instance.
For preventing this issue, we should make HTMLEditor have only the true-public
methods as public. The other public methods should be protected and their
users should be friend classes. Then, we can protect such method from external
classes.
Note that this patch just moves the methods without any changes in HTMLEditor.h
(except removes BlockTransformationType since it's unused and replaces
ResizingRequestID with new enum class ResizeAt since normal enum isn't hit by
searchfox.org).
MozReview-Commit-ID: 7PC8E8vD7w2
--HG--
extra : rebase_source : 13f51565f2b89ab816ba529af18ee88193a9c932
TextEditor has 2 type of public methods. One is true-public methods. I.e.,
they should be able to be called by anybody. E.g., command handlers, event
listeners, or JS via nsIEditor interface. The other is semi-public methods.
They are not called by the above examples but called by other classes which
are helper classes to handle edit actions. E.g., TextEditRules, HTMLEditRules,
HTMLEditUtils, CSSEditUtils and Transaction classes.
When we will implement InputEvent.inputType, we need to create new stack
class and create its instance at every true-public methods to manage current
inputType (like TextEditRules::AutoSafeEditorData). Therefore, it should not
happen that new code starts to call semi-public methods without the new
stack class instance.
For preventing this issue, we should make TextEditor have only the true-public
methods as public. The other public methods should be protected and their
users should be friend classes. Then, we can protect such method from external
classes.
Note that this patch just moves the methods without any changes in TextEditor.h.
MozReview-Commit-ID: Db3H6d1V8IU
--HG--
extra : rebase_source : d928a6bb378d02944c5a207de83211c33bb63613
EditorBase (and other editor classes) have 2 type of public methods. One is
true-public methods. I.e., they should be able to be called by anybody.
E.g., command handlers, event listeners, or JS via nsIEditor interface.
The other is semi-public methods. They are not called by the above examples
but called by other classes which are helper classes to handle edit actions.
E.g., TextEditRules, HTMLEditRules, HTMLEditUtils, CSSEditUtils and Transaction
classes.
When we will implement InputEvent.inputType, we need to create new stack
class and create its instance at every true-public methods to manage current
inputType (like TextEditRules::AutoSafeEditorData). Therefore, it should not
happen that new code starts to call semi-public methods without the new
stack class instance.
For preventing this issue, we should make EditorBase have only the true-public
methods as public. The other public methods should be protected and their
users should be friend classes. Then, we can protect such method from external
classes.
Note that this patch just moves the methods without any changes in EditorBase.h
(except removes GetName() since there is no body of this method and removes
IterDirection since it's unused).
MozReview-Commit-ID: HBseKLL6pxx
--HG--
extra : rebase_source : 2251ff659d831d01a6778d38f4e2714fcf2d6ef4
HTMLEditRules::GetNodesFromPoint() uses ErrorResult only for checking in
debug build. So, it should use IgnoredErrorResult instead.
MozReview-Commit-ID: 5roQI03A0kF
--HG--
extra : rebase_source : 5f54dc18635653d214b22520f4747a00258d9d9b
This patch adds new rules of TextEditRules and HTMLEditRules about
NS_ERROR_EDITOR_DESTROYED.
Additionally, this patch moves some method explanation in each .cpp file to .h
file.
MozReview-Commit-ID: JqZFrWyrND8
--HG--
extra : rebase_source : d86385d9c26bb23adae1eca3b1be1a868c20e353
Additionally, it creates AutoSelectionRestorer. So, this patch adds
CanHandleEditAction() check after its caller since even if it returns
NS_OK, the editor might have been gone.
MozReview-Commit-ID: BgIbpHFFPE1
--HG--
extra : rebase_source : 010befdb34f8269f6f7fc24d1ae13eba4575aa69
And this patch creates a new method, OutdentAroundSelection(), to check if
restoring Selection with AutoSelectionRestorer causes destroying the editor.
However, this does NOT change any logic in the new method except changing some
else-if blocks to if blocks with early-return style.
MozReview-Commit-ID: JMIo4kUOkwx
--HG--
extra : rebase_source : 0d628ebb866d7b63f8b78e6d701c27378a82dfb6
And this patch renames it to SplitRangeOffFromBlockAndRemoveMiddleContainer()
for making the name explain what it does.
MozReview-Commit-ID: 546dnCeoGOV
--HG--
extra : rebase_source : 7f0762cfa377a07d28342a1092ad0a7ee70fa108
And this patch renames it to SplitRangeOffFromBlock() for making the name
explain what it does since "split" is used as splitting to two nodes widely
in editor.
MozReview-Commit-ID: GrRu5sI4yrP
--HG--
extra : rebase_source : 3ec27bce3769af518d3f1c317559fd89d379c539
Additionally, this patch renames it to MaybeDeleteTopMostEmptyAncestor() for
making its name explain what it does.
MozReview-Commit-ID: 1i7zeq9In2T
--HG--
extra : rebase_source : 8d9de9e6154038a993be636c3cedf950a6efd179
PromoteRange() related methods do not change Selection nor the DOM tree.
Therefore, they must be safe. However, only PromoteRange() takes an nsRange
instance and modifies it. If it's in Selection, that causes selectionchange
event. Therefore, we should check if given range is in Selection with
MOZ_ASSERT().
MozReview-Commit-ID: AXkmHFB4P08
--HG--
extra : rebase_source : 539b39d0217a7dc06f76e70546096d30b2734c02
Despite of the name of GetNodesForOperation() and related methods, it changes
the DOM tree if their aTouchContent is TouchContent::yes (by default).
Therefore, they should return NS_ERROR_EDITOR_DESTROYED if they cause destroying
the editor and all callers should check the result. Therefore, this patch mark
them as MOZ_MUST_USE.
Additionally, because of importance of aTouchContent, this patch makes the
arguments not optional. This change must make other developers being careful
to use them. (Although TouchContent does not feel dangerous. We should rename
it to make its risk clearer.)
On the other hand, this patch removes aTouchContent from
GetParagraphFormatNodes() since it's always called with TouchContent::no.
Therefore, this method is always safe.
Although I tried to document those methods, but I have not understood them
completely yet. Perhaps, we should redesign them in another bug both to
learn them and making them faster and simpler.
MozReview-Commit-ID: 4vknJGUdwEe
--HG--
extra : rebase_source : 486949005283548697e6eeb7175f6189a66defaa