When we implement InputEvent.inputType, we need to set a stack class to record
which edit action is currently handled. However, currently, we call smaller
jobs as edit action. For example, when user types a character at selecting
some characters, then, EditAction::deleteSelection is performed first, then,
EditAction::insertText is performed. However, for the InputEvent.inputType,
we need inserText information. So, for making new enum EditAction, we need
to rename current EditAction to EditSubAction.
And also this renames related stuff:
EditorBase::mIsInEditAction -> EditorBase::mIsInEditSubAction
EditorBase::IsInEditAction() -> EditorBase::IsInEditSubAction()
EditorBase::mAction -> EditorBase::mTopLevelEditSubAction
TextEditRules::mTheAction -> TextEditRules::mTopLevelEditSubAction
EditorBase::StartOperation() ->
EditorBase::OnStartToHandleTopLevelEditSubAction()
EditorBase::EndOperation() ->
EditorBase::OnEndHandlingTopLevelEditSubAction()
AutoRules -> AutoTopLevelEditSubActionNotifier
RulesInfo -> EditSubActionInfo
MozReview-Commit-ID: cvSkPUjFm1
--HG--
extra : rebase_source : baf527a3e353b7a8ebe9a46be2243b059c500234
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
