EditorBaseTransaction::CreateTxnForDeleteNode() just hides what it does.
Instead, let's create a factory method, DeleteNodeTransaction::MaybeCreate()
for making callers clearer.
MozReview-Commit-ID: 8WUYN0BjKSU
--HG--
extra : rebase_source : e0ff8b8434b720dc124c770cd7371d84b949ca8d
DeleteTextTransaction should have 3 factory methods. One is, simply to create
an instance with a pair of offset and length. The others are, to create an
instance for deleting a previous or next character at offset.
The former was EditorBase::CreateTxnForDeleteText() and the latter was
EditorBase::CreateTxnForDeleteCharacter(), but this patch creates
DeleteTextTransaction::MaybeCreate() for the former,
DeleteTextTransaction::MaybeCreateForPreviousCharacter() and
DeleteTextTransaction::MaybeCreateForNextCharacter() for the latter.
MozReview-Commit-ID: DFELbmAJDo3
--HG--
extra : rebase_source : 1600984c704b460e1cc09777b81df2906c154cce
EditorBase::CreateTxnForComposition() just hides what it does. For its caller,
creating a factory method, CompositionTransaction::Create(), is clearer what
it does.
Additionally, capsuling the creation in CompositionTransaction class can make
the text node information in TextComposition updated automatically. So, now,
it might be better to update them in DoTransaction() because there is a lag
between creating the transaction and calling DoTransaction(). However, this
patch doesn't want to change any existing behavior. So, this doesn't fix this
issue.
MozReview-Commit-ID: K8ci7ytwh1u
--HG--
extra : rebase_source : d468a0fc997c99f78f7eb46451082e7f1e052890
EditorBase::CreateTxnForCreateElement() just hides what it does. Let's make
the caller what it does with creating CreateElementTransaction::Create().
MozReview-Commit-ID: DYcfQV6KiUZ
--HG--
extra : rebase_source : d3f31b8db92bd3b2af464c66e064dd7b21018960
EditorBase::CreateTxnForInsertNode() just hides what it does. Let's create
InsertNodeTransaction::Create() and make the caller clearer.
MozReview-Commit-ID: 2J2WV73cdsm
--HG--
extra : rebase_source : 15b6391aee5beca4401e7c7a4ee8bf350a7590fd
EditorBase::CreateTxnForInsertText() just hides what it exactly does.
Rewriting it with a static factory method, InsertTextTransaction::Create()
should be clearer for its caller.
MozReview-Commit-ID: Er7Zlhtbnb0
--HG--
extra : rebase_source : 9dc71b3baab839f61153b96806fac5baae5d46cb
The only caller is HTMLEditor::IsEmptyNodeImpl(). So, we can get rid of it.
MozReview-Commit-ID: GTJiXwSCrwM
--HG--
extra : rebase_source : a44b277547d0641f244ff363f5cde8ae44b13eda
mInlineEditedCell for inline table editor is still nsIDOMElement. To avoid QI
and virtual call, we should replace it with Element.
MozReview-Commit-ID: 76yfQJxwm9d
--HG--
extra : rebase_source : e89de17faa20d16a8823e1016b6ba8a6f78993b6
Most arguments of the constructor of CompositionTransaction are now stored by
EditorBase::mComposition. So, making it take TextComposition reduces the
number of its arguments.
Note that this patch doesn't make it retrieve TextComposition with
EditorBase::GetComposition() for guaranteeing that the editor has non-nullptr
mComposition.
MozReview-Commit-ID: 3O5wL52UBUy
--HG--
extra : rebase_source : 7f48465ef3f2f040e8c526fb7837060ecb6c9147
EditorBase stores a text node, offset in it and length in it of composition
string directly. However, this wastes memory space if user never uses IME
or user only sometimes uses IME. Additionally, storing all data in
TextComposition is better than current design when other classes like
CompositionTransaction wants some information of both EditorBase and
TextComposition.
This patch moves those 3 members from EditorBase to TextComposition.
MozReview-Commit-ID: 4N7wmGGfxmt
--HG--
extra : rebase_source : bd7cb37fe9631b959ec21da40c20751fec269dca
nsIEditorSpellCheck still uses wstring. We should replace it with AString
to avoid additional memory allocation.
MozReview-Commit-ID: H4jKY2tylqg
--HG--
extra : rebase_source : c1f0325eb2efbfb07f53514b96121a5ceb58efd4
HTMLEditRules::StandardBreakImpl() should take |const EditorDOMPoint&| to
specify where a new <br> element inserted before.
Additionally, we should rename it to InsertBRElement().
MozReview-Commit-ID: 4BR7xGFFrpk
--HG--
extra : rebase_source : 873af2c4167227a570878fe03d6dec61dffe9528
TextEditRules has some wrappers of TextEditor::CreateBR(). Also they should
take |const EditorRawDOMPoint&| to specify the insertion point of new <br>
element.
Additionally, this patch makes them just return add-refed Element instead of
nsresult. So, we can get rid of out param from it.
MozReview-Commit-ID: 3wfKGaTM89c
--HG--
extra : rebase_source : 47f0d89bc16f0858c7141b2035164adb9105493c
TextEditor::CreateBR() should take |const EditorRawDOMPoint&| to specify the
insertion point instead of a set of container node and offset in it.
MozReview-Commit-ID: 4PrWzwmIgfD
--HG--
extra : rebase_source : c509907002693f3b77cd00bf77cfd0f26704fd65
Different from RangeBoundaryBase, EditorDOMPointBase can store only child node.
I.e., mOffset may be invalid until its Offset() is called. So,
GetChildAtOffset() isn't good name. It should be just GetChild().
Similarly, GetNextSiblingOfChildAtOffset() and
GetPreviousSiblingOfChildAtOffset() should be renamed to GetNextSiblingOfChild()
and GetPreviousSiblingOfChild().
MozReview-Commit-ID: WpkPmDwkrL
--HG--
extra : rebase_source : 2be1fcbee129f4c96e9b166be5a924845340708f
EditorDOMPointBase::Container() may return nullptr. So, it should be renamed
to GetContainer().
Then, the method name becomes longer and a lot of callers access the result
directly. So, there should be following methods to make the callers shorter:
- GetContainerAsContent() to return the container as nsIContent*.
- GetContainerAsElement() to return the container as dom::Element*.
- GetContainerAsText() to return the container as dom::Text.
- GetContainerAsDOMNode() to return the container as nsIDOMNode*.
- CanContainerHaveChildren() to check if the container can have child nodes.
- IsInDataNode() to check if the point is in a data node including text node.
- IsInTextNode() to check if the point is in a text node.
- IsContainerHTMLElement() to check if the container is specific HTML element.
- IsContainerAnyOfHTMLElements() to check if the container is one of the
specified HTML elements.
MozReview-Commit-ID: LkN2WBbCPj0
--HG--
extra : rebase_source : 9da1e70d4c74f7ad573e244cf6c7b21a0c7b4410
Editor code sometimes sets a DOM point to end of a node. In this case, we
need to write |Set(node, node->Length())|. So, it should have
|void SetToEndOf(const nsINode* aContainer)| for making meaning of the code
clearer.
MozReview-Commit-ID: 91shMCD2d84
--HG--
extra : rebase_source : 3401af50aabc1b677deeae664e8c56506182d28c
Even after EditorBase::DeleteSelectionAndCreateElement() creates a new element,
it tries to collapse selection with |pointToInsert| which is outdated after
inserting new element.
So, it should recompute the caret position with new DOM tree.
MozReview-Commit-ID: DKh2uhItIol
--HG--
extra : rebase_source : c0c30e1c809784af64e87596b471c472350857a8
nsRange::SetStart(), nsRange::SetEnd(), nsRange::IsPointInRange() and
nsRange::ComparePoint() take a set of container node and offset in it to
specifying a DOM point. However, the caller may not have computed the offset
but may know the child node at the point. In such case, they can avoid
computing the offset with nsINode::IndexOf() if they have overloads which
take RawRangeBoundary.
Therefore, this patch implements the overloads and changes the callers in
editor.
MozReview-Commit-ID: E4DLbAgTTCI
--HG--
extra : rebase_source : 8d1632a030f1e0a0dd2b81c3996c19d427e8b0bd
Some methods of editor retrieves anchor and focus of selection. However, there
are no methods which directly access RangeBoundary of anchor and focus.
This patch adds it for making editor code simpler and avoiding unnecessary
child offset computation.
MozReview-Commit-ID: EvepQpFMi8S
--HG--
extra : rebase_source : 38f3c506db5c9d8790bbd625d552bfbc8d99cebc
HTMLEditor::NormalizeEOLInsertPosition() takes a set of container node and
offset in it for specifying insertion point. So, this should be replaced
with |const EditorRawDOMPoint&| and it should return |EditorDOMPoint| rather
than modifying the argument.
Additionally, perhaps, GetBetterInsertionPointFor() is better name for it.
MozReview-Commit-ID: IB1FhrkzK2G
--HG--
extra : rebase_source : 55f8c1d9fa1f149e81114c929f6e6232aba03905
HTMLEditor::InsertNodeAtPoint() should take |const EditorRawDOMPoint&| as
an argument which specifies point to insert. Additionally, it should take
|EditorDOMPoint*| to return the next point of actual insertion point.
Additionally, this patch renames it to InsertNodeAtProperAncestor() for
explaining what it will do.
MozReview-Commit-ID: HYUzSlyPxAd
--HG--
extra : rebase_source : 57033cdc4458b45a5fe9d6aa642c185133a79304
Although nsIEditActionListener::WillInsertNode() nobody implements actually,
we should remove it in a follow up bug.
nsIEditActionListener::DidInsertNode() is implemented only by HTMLEditRules.
So, if we make it not use nsIEditActionListener, we can remove it too.
However, keep it for now.
On the other hand, they don't need to receive index of the insertion point.
WillInsertNode() needs next sibling of the insert point, but DidInsertNode()
needs nothing because listener can compute it with new inserted node.
MozReview-Commit-ID: GiTKkVyZJlN
--HG--
extra : rebase_source : 9ee38c28217d25d1a3f79b0b458c7b2121350a76
EditorBase::CreateTxnForInsertNode() and EditorBase::InsertNode() should take
|const EditorRawDOMPoint&| as an argument specifying point to insert.
MozReview-Commit-ID: KhK19xS7wXb
--HG--
extra : rebase_source : f7b08b7d049eef8a9c03ee681e53e8d469915b15
Like CreateNodeTransaction, InsertNodeTransaction should use EditorRawDOMPoint
for temporary variable and arguments of its methods and should use RangeBoudary
to store it as its member.
MozReview-Commit-ID: FCGY8x97egb
--HG--
extra : rebase_source : bd5ce45944b8b367afc9b782e881727061d83035
EditorDOMPoint was a subclass of RangeBoundary. Therefore, for heavy
use of it in editor, we've implemented a lot of complicated feature
into RangeBoundary. However, EditorDOMPoint stopped inheriting
RangeBoundary. So, we can get simple RangeBoundary implementation
back now.
This patch makes RangeBoundary.h almost same as 3f7cbec2446b except
keeps implementing GetPreviousSiblingOfChildAtOffset() and
GetNextSiblingOfChildAtOffset() because the former is used by
Selection and both of them are simple. And also keeps making it
a friend of EditorDOMPoint because EditorDOMPoint still needs to
copy to/from RangeBoundary.
MozReview-Commit-ID: Hr5SA52ScK0
--HG--
extra : rebase_source : a00a46ff931a5c4fcabf910510fa448b513f50c5
The name, WSRunObject::CheckTrailingNBSP(), is unclear what it does. It
replaces previous character of specified point with ASCII space if it is NBSP
and it's not necessary.
So, it should be renamed to ReplacePreviousNBSPIfUnncessary().
Additionally, it should take |const EditorRawDOMPoint&| instead of a set of
container node and offset in it.
MozReview-Commit-ID: 2vq46OiAzo6
--HG--
extra : rebase_source : 132bb71361ff1e60268863cd4ef86bfbd0ddc9d1
WSRunObject::GetChar(After|Before)(nsINode*, int32_t) returns next/previous
character's DOM point as WSPoint. If the container node is a text node in
mNodeArray, it calls WSRunObject::GetChar(After|Before)(const WSPoint&) which
returns next/previous offset if the point isn't end/start of the text node.
If the point is at end/start of the text node, it returns start/end of
next/previous text node in mNodeArray. If the container node is not a text
node in mNodeArray, it calls WSRunObject::GetWSPoint(After|Before)(). It looks
for next/previous text node in mNodeArray from the point. Then, it calls
WSRunObject::GetChar(After|Before)(const WSPoint&) and returns the result.
So, we should rename GetCharAfter() to GetNextCharPoint(), GetCharBefore() to
GetPreviousCharPoint(), GetWSPointAfter() to GetNextCharPointInternal() and
GetWSPointBefore() to GetPreviousCharPointInternal().
Then, they should take |const EditorRawDOMPoint&| instead of a set of container
node and offset in it.
So, looks like that "WS"RunObject is not good name for this class, perhaps,
AutoTextRunManager or something? But I'm still not sure.
MozReview-Commit-ID: 85cX3MdlFwz
--HG--
extra : rebase_source : 217dbb75653bf2a4c593fb9a0498824b1b764cf4
WSRunObject::DeleteChars() should take two |const EditorRawDOMPoint&| arguments
to represent a range to remove.
Additionally, this renames it to DeleteRange() because it also removes any
nodes in the range. So, "Chars" isn't good word for this method's name.
MozReview-Commit-ID: 5Dmxnia1JPO
--HG--
extra : rebase_source : a4fd44c9354762db0e37fa156790dc20fdbe23a1
WSRunObject::FindRun() finds the nearest run from aPoint to specified direction.
So, it uses nsContentUtils::ComparePoints() a lot. Therefore, it should use
an overload which takes RawRangeBoundary. Although, it's not optimized for
RawRangeBoundary, but if it'd be optimized, this method becomes faster.
And this patch renames it to FindNearestRun().
MozReview-Commit-ID: 2NkR5E1st6d
--HG--
extra : rebase_source : 387ecc9d483c7cd88306197391fc2940b2000e28
WSRunObject::InsertBreak() should take |const EditorRawDOMPoint&| instead of
a pair of container node and offset in it.
MozReview-Commit-ID: 38OAn4dvR7x
--HG--
extra : rebase_source : 8e48ba2cec07c1dd4daf3cd9ec44751c860bc3da
TextEditor::CreateBRImpl() should take |const EditorRawDOMPoint&| as insertion
point of new <br> element. Additionally, it doesn't need to have out argument
for the point of after <br> element because callers can get it with
EditorRawDOMPoint(nsINode*) and the new <br> node, and calling AdvanceOffset().
This cost must be enough cheap.
MozReview-Commit-ID: Hxawz3D2dCd
--HG--
extra : rebase_source : 866ff50efd70499ed733da9efcce7399f44bd4a0
While moving children of a container to another container, mutation observer
may move children before moving and/or move node immediately after the
insertion point. Therefore, EditorBase should store all children which
should be moved with a local variable. Then, move one by one carefully.
E.g., if a child before being moved is moved to different container, it
shouldn't be moved because JS already handles it as expected for the web
app. If next sibling of the insertion point has been moved, EditorBase
should stop moving the remaining children because it may move children to
odd position and it may cause dataloss.
This patch creates EditorBase::MoveChildren() and it moves children carefully
with above checks. Additionally, making its callers simpler, this patch also
creates EditorBase::MovePreviousSiblings() and MoveAllChildren().
MozReview-Commit-ID: FJDdSqXIlqD
--HG--
extra : rebase_source : 54bded29dbbd9547339a2c6e1a1264e22fbdc740
nsITextServicesDocument isn't scriptable, so there is no reason to use
nsIDOMRange.
MozReview-Commit-ID: AVPgrwmz38H
--HG--
extra : rebase_source : 0cb03cdb9b0dc4ef85b1b5582b7e3a54cb002904
nsTextServicesDocument still use nsIDOMNode, so we should replace with nsINode
to reduce QI.
MozReview-Commit-ID: 7G9w31dRFi9
--HG--
extra : rebase_source : 322ae89f42183fe780b408f2ceb1c6d699ade985
CreateElementTransaction and SplitNodeTransaction store DOM point with
RangeBoundary now. However, it refers next child of referring point.
Therefore, if it's moved to different container or removed from the DOM
tree, they cannot do undo/redo. We can say for the child node, however,
it doesn't make sense depending on a node which is not directly referring.
MozReview-Commit-ID: Baohbub3RNZ
--HG--
extra : rebase_source : 6776420271cdaf91aae6213fb6e1bcf1841112b1
EditorDOMPointBase should store child node at offset directly rather than
previous sibling of child node at offset because if referring child node or
its previous sibling is moved to different DOM point,
EditorDOMPointBase::GetChildAtOffset() may return different node. However,
users of this class assumes that after it stores child node at offset, it'll
return same node.
So, EditorDOMPointBase should store child node instead of "ref". Additionally,
when it stores nullptr as the child, it should set mOffset to length of the
mContainer because it means it refers after the last child.
MozReview-Commit-ID: 7ZdkwKLJEjo
--HG--
extra : rebase_source : c2a0a1be1285466e5fa96162779e86c37ae78655
EditorDOMPointBase should store child at offset for editor uses. E.g., when
editor wants to refer a node as child node of an EditorDOMPoint instance,
even if the node is unexpectedly moved to different container, editor wants
to keep referring the child node rather than its previous sibling.
Therefore this patch makes EditorDOMPointBase not a sub class of
RangeBoundaryBase but copying all methods and members of RangeBoundaryBase
into EditorDOMPointBase for keeping current behavior completely.
MozReview-Commit-ID: LIyPFkCfsZ9
--HG--
extra : rebase_source : fd76c4808625f8f8a86f7b4e4c1ac22fbdc11dd5
There are 3 spam warning assertion in EditorDOMPointBase.
One is in constructor. Which warns if IsSet() returns false, but it checks
before finishing initializing.
The others are in IsStartOfContainer() and IsEndOfContainer(). They try to
check if mOffset is valid value with current DOM tree if it's initialized
when it's at start or end of the container. However, they do it even when
it's not start nor end of the container.
This patch fixes those spammers.
MozReview-Commit-ID: DvFa501m9V0
--HG--
extra : rebase_source : c97ac371054a54eabc07b3ec726b924d6be61e25
