It'd be better to change copy constructor of `EditorDOMPointBase` to explicit,
but it'd require too many changes in editor code. So, this patch just changes
each method callers only.
Differential Revision: https://phabricator.services.mozilla.com/D30054
--HG--
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
As far as I've tested, Chrome does not throw exception even when editor is
destroyed or editor content is modified unexpectedly. So, we should return
`NS_OK` from most public methods of editor when internal methods return
`NS_ERROR_EDITOR_DESTROYED` or `NS_ERROR_EDITOR_UNEXPECTED_DOM_TREE`.
Differential Revision: https://phabricator.services.mozilla.com/D20811
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data when the event
is caused by `document.execCommand()` with `backColor`, `foreColor` nor
`hiliteColor`, Safari supports styling color with touchbar and in that case,
Safari sets it (*1).
Additionally, currently Safari uses `rgb()` to represents a color value and
using same rule to serializing color value for CSS OM matches Safari's behavior
and can represent any valid color values.
This patch makes given color value parsed and then serialized with same code
in style system. If the value is `currentcolor`, `inherit`, `initial` or `reset`, sets
the value as-is for now. Additionally, when given value is invalid, sets the value
as-is for forward compatibility.
Note that automated tests will be added into input-events-exec-command.html
by the last patch.
1. https://github.com/w3c/input-events/issues/94#issuecomment-461061517
Differential Revision: https://phabricator.services.mozilla.com/D19295
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data value when
InputEvent.inputType is "fontName", but it's easy to implement. Therefore, this
patch implements it as declaration of Input Events.
This patch uses given value as-is. Perhaps, this shouldn't cause any problems
because such value can be set to Element.style.fontFamily without any changes.
Note that automated test will be added into WPT later.
Differential Revision: https://phabricator.services.mozilla.com/D19294
--HG--
extra : moz-landing-system : lando
This patch makes ContentIteratorBase, PostContentIterator, PreContentIterator
and ContentSubtreeIterator classes non-refcountable because most users can
create their instances in stack and such users may be in a hot path. So,
we can save a lot of cost of instantiation.
Unfortunately, only ScriptableContentIterator creates one of the concrete
classes and needs to destroy it properly. Therefore, its
EnsureContentIterator(), destructor, traverse and unlink code becomes messy.
However, ScriptableContentIterator was designed for automated tests and we
need to maintain it not so many times. Therefore, improvement of other
users must be worthwhiler than this demerit.
Differential Revision: https://phabricator.services.mozilla.com/D15928
--HG--
extra : moz-landing-system : lando
Now, all users of PostContentIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15923
--HG--
extra : moz-landing-system : lando
Now, all users of ContentSubtreeIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15920
--HG--
extra : moz-landing-system : lando
This patch makes ContentIteratorBase, PostContentIterator, PreContentIterator
and ContentSubtreeIterator classes non-refcountable because most users can
create their instances in stack and such users may be in a hot path. So,
we can save a lot of cost of instantiation.
Unfortunately, only ScriptableContentIterator creates one of the concrete
classes and needs to destroy it properly. Therefore, its
EnsureContentIterator(), destructor, traverse and unlink code becomes messy.
However, ScriptableContentIterator was designed for automated tests and we
need to maintain it not so many times. Therefore, improvement of other
users must be worthwhiler than this demerit.
Differential Revision: https://phabricator.services.mozilla.com/D15928
--HG--
extra : moz-landing-system : lando
Now, all users of PostContentIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15923
--HG--
extra : moz-landing-system : lando
Now, all users of ContentSubtreeIterator can access it directly. This patch
makes them use the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D15920
--HG--
extra : moz-landing-system : lando
After fixing bug 1427060, HTMLEditor treats attribute of style as nullptr.
However, if empty string is used to call NS_Atomize(), it returns
nsGkAtoms::_empty. Therefore, HTMLEditor fails to check whether attribute is
specified or not with nullptr check since some root callers sets
nsGkAtoms::_empty instead of nullptr.
This patch makes HTMLEditor always use nullptr for empty string of attribute
of style with wrapping NS_Atomize() with AtomzieAttribute(). Additionally,
for safer change, this patch makes PropItem and TypeInState treat
nsGkAtom::_empty as nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D13203
--HG--
extra : moz-landing-system : lando
Similar to EditorBase::mSavedSel, we can move EditorBase::mRangeUpdater too
because of it's referred only when there is AutoEditActionDataSetter instance
so that it also does not need to be in the cycle collection.
And now, it can be marked as MOZ_STACK_CLASS and remove cycle collection
support.
Differential Revision: https://phabricator.services.mozilla.com/D12402
--HG--
extra : moz-landing-system : lando
Now, any protected/private methods of editor classes can refer
SelectionRefPtr() safely. So, we can cut the cost of calling GetSelection()
only once per edit action handling.
Differential Revision: https://phabricator.services.mozilla.com/D10011
--HG--
extra : moz-landing-system : lando
When each method of TextEditRules and HTMLEditRules should be called only by
EditorBase/TextEditor/HTMLEditor while the editor instance has
AutoEditActionDataSetter instance. Therefore, we can get rid of all
pointers/references of Selection from each method's argument.
Additionally, this reimplements TextEditRules::SelectionRef() with
EditorBase::SelectionRefPtr() and make it return |const RefPtr<Selection>&|
rather than |Selection&| since RefPtr reference is required when we call
methods which are marked as MOZ_CAN_RUN_SCRIPT.
Differential Revision: https://phabricator.services.mozilla.com/D10010
--HG--
extra : moz-landing-system : lando
EditorBase::SelectionRefPtr() is now safe to use in editor and really fast to
retrieve Selection than EditorBase::GetSelection(). Therefore, we can get rid of
all Selection pointer/reference argument of each method which always take
normal Selection.
Note that this changes nsIHTMLEditor.checkSelectionStateForAnonymousButtons()
because its argument is only Selection. So, BlueGriffon should work even
though it calls the method with nsIEditor.selection.
Differential Revision: https://phabricator.services.mozilla.com/D10009
--HG--
extra : moz-landing-system : lando
AutoTransactionBatch, AutoPlaceholderBatch, AutoSelectionRestorer,
AutoTopLevelEditSubActionNotifier, AutoTransactionsConserveSelection and
AutoUpdateViewBatch access protected members of EditorBase. The access
scope management assume that they are used only by EditorBase or its
subclasses or TextEditRules or its inherited class (i.e., HTMLEditRules).
For guaranteeing this at build-time, we should change them to nested classes
of EditorBase. Then, EditorBase and its subclasses and friends can use them.
Differential Revision: https://phabricator.services.mozilla.com/D9479
--HG--
extra : moz-landing-system : lando
StyleUpdatingCommand::ToggleState() removes exclusive style when it sets
superscript style or subscript style. However, it accesses protected
members of EditorBase via AutoTransactionBatch even though it's outside
of editor classes.
This patch moves the removing exclusive style code from the method to
HTMLEditor::SetInlineProperty() and rename it "AsAction".
Differential Revision: https://phabricator.services.mozilla.com/D9477
--HG--
extra : moz-landing-system : lando
Even though HTMLEditor::GetIsCSSEnabled() is an implementation of an XPCOM
method, it uses nsresult as its return type. We should change it to
NS_IMETHODIMP.
Additionally, SetDocumentStateCommand::GetCommandStateParams() calls this,
but HTMLEditor can expose non-virtual method, HTMLEditor::IsCSSEnabled().
Therefore, this patch makes it public and makes SetDocumentStateCommand use
HTMLEditor::IsCSSEnabled().
Differential Revision: https://phabricator.services.mozilla.com/D4304
--HG--
extra : moz-landing-system : lando
Neither comm-central nor BlueGriffon uses nsIHTMLEditor.getFontColorSetate().
So, we can get rid of this from nsIHTMLEditor. However, we need to keep it
as a non-virtual public method since it's used by FontColorStateCommand.
Differential Revision: https://phabricator.services.mozilla.com/D4303
--HG--
extra : moz-landing-system : lando
For making it possible to distinguish if HTMLEditor::RemoveInlineProperty() is
called by outer class or editor itself, this patch creates
Create HTMLEditor::RemoveInlinePropertyInternal() and makes the internal
callers use this new method.
Differential Revision: https://phabricator.services.mozilla.com/D3000
--HG--
extra : moz-landing-system : lando
For making it possible to distinguish if SetInlineProperty() is called by outer
class or the editor itself, this patch creates SetInlinePropertyInternal().
Additionally, this makes the first argument of SetInlineProperty() from
nsAtom* to nsAtom& since it's not nullable.
Differential Revision: https://phabricator.services.mozilla.com/D2999
--HG--
extra : moz-landing-system : lando
SplitStyleAbovePoint calls SplitNodeDeepWithTransaction repeatedly. If
SplitNodeDeepWithTransaction creates orphan node like this test case,
this crash occurs. So we should check whether node becomes orphan node.
Differential Revision: https://phabricator.services.mozilla.com/D1993
--HG--
extra : moz-landing-system : lando
It's always created with non-nullptr. So, making it treat reference of
EditorBase makes its implementation simpler.
Note that this changes comment in EditorBase::InsertTextWithTransaction() to
a MOZ_ASSERT() for detecting bugs. However, the comment is wrong. When
the insertion is for updating composition string, callers don't need to create
AutoTransactionsConserveSelection since it'll be ignored by
CompositionTransaction. So, the new MOZ_ASSERT() checks whether it's
in composition or prevented transaction changing Selection.
MozReview-Commit-ID: 6jZ4LpksyoD
--HG--
extra : rebase_source : 61ca9272ddea165b3691cf1ce42dc6f4df099a36
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
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
Similar to EditorBase::ReplaceContainerWithTransaction(),
EditorBase::InsertContainerAbove() may set an attribute to newly created element
if it's specified. However, for avoiding the null check, let's make them
as references rather than pointers and treat nsGkAtoms::_empty as nullptr for
making the code safer.
This patch removes "Above" from the method name since it's redundant.
"Insert" sounds like inserting a node, and "Container" means to keep existing
children with new element in EditorBase.
MozReview-Commit-ID: 6EnkKHynYSP
--HG--
extra : rebase_source : d4b4c1a611c46a0f4d86389aab3331af565199d2
This patch renames EditorBase::MoveNode() to
EditorBase::MoveNodeWithTransaction() and redesign its parameters including
replacing a set of container node and offset in it to EditorDOMPointBase.
However, it takes magic number -1 as meaning end of the container.
Therefore, this patch adds MoveNodeToEndWithTransaction() for keeping the
callers simple.
MozReview-Commit-ID: BeTq5c7GQNN
--HG--
extra : rebase_source : b3a617a5a1a493cb0fcbefe2d9a9708b0257b1a8
This patch renames:
EditorBase::SplitNode() -> EditorBase::SplitNodeWithTransaction()
EditorBase::SplitNodeDeep() -> EditorBase::SplitNodeDeepWithTransaction()
HTMLEditRules::MaybeSplitAncestorsForInsert() ->
HTMLEditRules::MaybeSplitAncestorsForInsertWithTransaction()
Note it might be that some callers of those methods should be renamed too.
However, we should do it in follow up bug after landing those patches since
we can investigate it with searchfox.org after landing patches.
MozReview-Commit-ID: FfxCfaI85z5
--HG--
extra : rebase_source : 143960de45791c72dbf4d436f65e55452b4f7b10
Except table access and XPCOM methods for c-c, tests and etc, we can remove
more nsIDOMElement usages to avoid QI.
MozReview-Commit-ID: HO5kAaZAs6Q
--HG--
extra : rebase_source : 41ede0bace33504ad852dc4e0016ea346cd7bdee
Part 1. changes to static method, so caller should use scope operator instead
of mCSSEditUtils member.
MozReview-Commit-ID: GlCfyjlQgr0
--HG--
extra : rebase_source : f558fc833d5f3cb193a543fc1b05cdeb58f60ec1
extra : histedit_source : 741529204d2dddef0f2dab9e18055186155eca8f
