EditorBase::mInlineSpellChecker is always an instance of mozInlineSpellChecker.
Fortunately, it's easy to expose mozInlineSpellChecker.h. So, making EditorBase
store it as mozInlineSpellChecker directly, EditorBase can access any of
mozInlineSpellChecker, EditorSpellCheck, mozSpellChecker and
TextServicesDocument with new accessors created by following patch.
MozReview-Commit-ID: 2oyS5tPeQcg
--HG--
extra : rebase_source : a9ce2e4dbceff7ca800d34d60d56eba184298677
For making mozInlineSpellChecker stores nsEditorSpellCheck directly, we need
to expose its header file. For doing that this patch renames the class to
mozilla::EditorSpellCheck and expose it as "mozilla/EditorSpellCheck.h".
MozReview-Commit-ID: 5H66Y2vVshu
--HG--
rename : editor/composer/nsEditorSpellCheck.cpp => editor/composer/EditorSpellCheck.cpp
rename : editor/composer/nsEditorSpellCheck.h => editor/composer/EditorSpellCheck.h
extra : rebase_source : 7940aa136df312cd43bf592df1e71d2ac6c5dec8
nsEditorSpellCheck::mSpellChecker is always mozSpellChecker because it's
created only by nsEditorSpellCheck. Additionally, mozSpellChecker.h is
already exposed. So, nsEditorSpellCheck can store it as mozSpellChecker
directly.
MozReview-Commit-ID: 2vyDe4plncM
--HG--
extra : rebase_source : 847b2f384163450ab44b94bc12ee489633a849b6
nsITextServicesDocument isn't used by anybody now. So, we can get rid of it.
Additionally, nsITextService and nsTextServicesFactory are not also used by
anybody. Therefore, this patch removes all of them.
MozReview-Commit-ID: KSbMdm7QPKF
--HG--
extra : rebase_source : 724a5f48ad49b4231bacf7fba32c6a35d90121d0
Now, TextServicesDocument can be treated by anybody. So, let's make
mozSpellChecker and nsEditorSpellChecker treat it directly instead of
nsITextServicesDocument.
MozReview-Commit-ID: 2tMy6y3i17b
--HG--
extra : rebase_source : 2e6c79355a5e0a7044fbea989ba414a7bf1a7d8d
For making nsTextServicesDocument accessible from anywhere directly, we need to
expose its header. Then, it should be in mozilla namespace.
This patch renames nsTextServicesDocument to mozilla::TextServicesDocument
and expose the header file as "mozilla/TextServicesDocument.h".
MozReview-Commit-ID: 9PmP73PXSJu
--HG--
rename : editor/txtsvc/nsTextServicesDocument.cpp => editor/txtsvc/TextServicesDocument.cpp
rename : editor/txtsvc/nsTextServicesDocument.h => editor/txtsvc/TextServicesDocument.h
extra : rebase_source : a12081434d0bc002e3675178486cc7f8eaaa3256
nsTextServicesDocument stores editor with nsWeakPtr for avoiding circular
reference. However, both TextEditor and nsTextServicesDocument are cycle
collectable. So, we don't need to worry about the issue and we can simply
make it store with RefPtr<TextEditor>. Then, we can make EditorBase and
nsTextServicesDocument access each other directly.
MozReview-Commit-ID: 9I4U8ivFlov
--HG--
extra : rebase_source : 4880c6f7d706acc70324f58aee70d4311db44059
Most nsIEditActionListener::Will*() are not implemented, except
WillDeleteText() and WillDeleteSelection() which are implemented by
FinderHighlighter. So, we can get rid of the other Will*() from it.
This patch removes a lot of unnecessary virtual calls and copy of strong
pointers to edit action listeners of EditorBase.
MozReview-Commit-ID: EsqI2tZoBG1
--HG--
extra : rebase_source : cf78eb8d33b12ca65177b0676f6e45d02e7c0688
HTMLEditRules implements only some of nsIEditActionListener and this is always
first edit action listener. So, if we make EditorBase treat HTMLEditRules
directly before notifying edit action listeners, we can save a lot of runtime
cost (virtual calls especially unnecessary, copying array of edit action
listeners with strong pointer, redundant QIs), although the code becomes not
beautiful.
Perhaps, we should do same thing to nsTextServicesDocument and
mozInlineSpellChecker in other bugs.
MozReview-Commit-ID: Eveaxj398f2
--HG--
extra : rebase_source : 0b7b66ba1002e08591e8d95ef68b216e7ce1f93b
For calling some methods of mRules from EditorBase, let's move mRules member
from TextEditor to EditorBase.
Unfortunately, TextEditRules.h depends on EditAction which is declared in
EditorBase.h and that caused unnecessary include hell of EditorBase.h. So,
let's move it to an independent header file.
MozReview-Commit-ID: 5HiSZLP9WHH
--HG--
extra : rebase_source : 3e2c40385a6f3d6d1e03ef4e213434383bb37d5f
comm-central and bluegriffon don't use mosueDown, mouseUp and mouseMove in
nsIHTMLObjectResizer, so we should remove these methods from this interface.
MozReview-Commit-ID: BnSkkH7f0xc
--HG--
extra : rebase_source : 40811e1a0b714e3ef30fd9ac5e4f840241de3780
AutoMoveNodeSelNotify doesn't allow container is null. So we should reject
that parent of moving node is null.
MozReview-Commit-ID: DGNCicLJxuK
--HG--
extra : rebase_source : eea203f16d0296c74d0727f34b6ddc5c165f9092
This crashtest case hits assertion in SelAdjInsertNode due to invalid offset
point. So we check whether this is valid.
Also, SelAdjCreateNode and SelAdjInsertNode should use EditorRawDOMPoint to avoid offset calculation and check valid offset.
MozReview-Commit-ID: A1kaKEzc36e
--HG--
extra : rebase_source : c46843fdd6e9e18f49b9cedb008cda6cf3436811
This crash occurs when CreateNode returns nullptr that is error. So we should
check whether this method is failure.
MozReview-Commit-ID: 9jDOnEYSurG
--HG--
extra : rebase_source : a7f2f9797267befe99f7f794c524efdf7bf331c0
c-c and bluegriffon don't use this method, so let's remove it to clean up.
MozReview-Commit-ID: BC5Ooy2Jlb9
--HG--
extra : rebase_source : 86e49ef864d5c78049673924c385e6cdbd0cb215
Some methods in CSSEditUtils are unused now, so let's remove it.
MozReview-Commit-ID: H4HiqL6hW9K
--HG--
extra : rebase_source : 80e10ba5e6de5fcc5032dc2e08fa84bf26e80795
Actually, PopItem uses nsString to store attribute name. And when using it,
it converts to nsAtom by NS_Atomize and compare by nsString.
To reduce calculation of atom and string compare, we should store atom directly.
MozReview-Commit-ID: 8OB02mgMg1r
--HG--
extra : rebase_source : 9861217804acac52106a89cad75e08bd547080ad
extra : histedit_source : 2b9f01cf29b1b09dd07fc771ff94a06be4d94f31
WSRunObject::ConvertToNBSP() inserts an NBSP, then, removes following ASCII
whitespaces. When inserting an NBSP, mutation observer may change the
text node. In this case, it shouldn't keep working on removing ASCII
whitespaces because it may causes unexpected result.
This patch also renames ConvertToNBSP() and GetAsciiWSBounds() to
InsertNBSPAndRemoveFollowingASCIIWhitespaces() and
GetASCIIWhitespacesBounds() for making their jobs clearer.
MozReview-Commit-ID: TVy9fEKL6p
--HG--
extra : rebase_source : f0bce124055a86caca57334f06c75a46098f69ac
nsIEditRules is a super class of only mozilla::TextEditRules and not scriptable.
So, we can get rid of it.
This patch merges RulesInfo with TextRulesInfo and name new class is RulesInfo
for minimizing the code change.
Additionally, adds two methods AsHTMLEditRules() and its const version.
They make existing cast code safer.
MozReview-Commit-ID: KwWH3ADj3Bv
--HG--
extra : rebase_source : 4517bdc95b530530e9756e07c4b6cce78c002073
HTMLEditRules::IsEmptyBlock() won't return error in most cases. Additionally,
HTMLEditRules::WillInsertBreak() doesn't check it. So, just returning bool
is simpler.
MozReview-Commit-ID: 5DfRv7lIyuS
--HG--
extra : rebase_source : 8b430d88a92fd5830a0b9f1bc1d46ac31e45c12c
Despite of its name, HTMLEditor::IsVisTextNode() returns true with its out
argument when the given text node is empty. And although it returns nsresult,
it's almost always NS_OK because it returns error only when the editor isn't
usual condition.
So, it should return bool and true when the given text node is visible.
This patch separates the method. One is for checking the node with frames,
called IsInVisibleTextFrames(). The other is for checking it only with
its text, called IsVisibleTextNode().
MozReview-Commit-ID: EdQmkOxfNxO
--HG--
extra : rebase_source : ad9d42f6c8a8e17145f0ca92cd5c02994f8a6b37
Although, we don't need factory methods for DeleteRangeTransaction,
EditAggregateTransaction nor PlaceholderTransaction, for consistency with the
other transaction classes, they should have factory methods for making easier
to write the code.
For not making the performance slow down, they should be inline methods.
MozReview-Commit-ID: 7jl5yZNFYmP
--HG--
extra : rebase_source : 7cd5b5e268a670b3c8855407cc72dec12d34d8ff
This patch creates factory methods for ChangeStyleTransaction and removes
CSSEditUtils::CreateCSSPropertyTxn().
MozReview-Commit-ID: 1h8ZAj2PP5O
--HG--
extra : rebase_source : 3da3070ad179bac1aadbfc6984b4c2922a052ec0
This patch creates factory methods for AddStyleSheetTransaction and
RemoveStyleSheetTransaction, and removes EditorBase::CreateTxnForAddStyleSheet()
and EditorBase::CreateTxnForRemoveStyleSheet() instead.
MozReview-Commit-ID: 6dnZctDtNik
--HG--
extra : rebase_source : 43eaadbde06e4a0b061ea8136e12ffeccfaf5592
This patch creates two factory methods of ChangeAttributeTransaction. One is
for setting an attribute to specific value. The other is for removing an
attribute. So, EditorBase::CreateTxnForSetAttribute() and
EditorBase::CreateTxnForRemoveAttribute() are unnecessary anymore.
MozReview-Commit-ID: 2fEVd3pDXsf
--HG--
extra : rebase_source : 674005a5b9fc623999a0f51dc8697027970f06c9
EditorBase::CreateTxnForJoinNode() just hides what it does.
For making the caller clearer, let's create a factory method,
JoinNodeTransaction::MaybeCreate().
MozReview-Commit-ID: 8vADXdzMeuV
--HG--
extra : rebase_source : 6a281aff11bfa019c292d26cadd0cd29da12753f
SplitNodeTransaction::Create() just hides what it does. For making its caller
clearer, let's create a factory method, SplitNodeTransaction::Create().
MozReview-Commit-ID: KDiC8dDrLuQ
--HG--
extra : rebase_source : ac04544e10644b8a73375fb2b786e0bc86eb56ae
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
No one uses nsIInlineSpellChecker.spellCheckAfterEditorChange from script.
So I think we can mark this interface as noscript.
Since this method is scriptable, we need QI to get nsIDOMNode. If we can
change to noscript, it can reduce QI to get nsIDOMNode.
MozReview-Commit-ID: GC0WuFyTlaZ
--HG--
extra : rebase_source : 16ca9fc548e86747ac17407be48295c709174fb5
Part 1. moves native dom method of CreateBR, so we should use it for
CreateMozBR, and use native dom as parameter.
MozReview-Commit-ID: DHUB88HfowQ
--HG--
extra : rebase_source : 00fefd12b50bef0f1a9bd69e1b7992a19999d42f
One of CreateBR is still virtual method, but it is unnecessary to use it.
So we should remove virtual keyword and remove override method.
Also, we should move native dom version of CreateBR to TextEditor to use it
on TextEdtitor.
MozReview-Commit-ID: GCazJtY4urV
--HG--
extra : rebase_source : 8e0d71631f0070a928bc0f4817dd6efe7c833f1b
When TextEditor::CreateBRImpl() splits a text node before inserting new <br>
element, it initializes pointToInsertBrNode only with the right text node.
Then, it refers its Offset() after inserting new <br> node before the point.
Therefore, the offset is computed with the new DOM tree. So, adding 1 to
the offset is redundant only in this case.
So, before calling CreateNode(), it needs to make pointToInsertBrNode store
offset with calling its Offset().
Note that this ugly code will be replaced with patches for bug 1408227.
Additionally, this doesn't use AutoEditorDOMPointChildInvalidator because
it's not available in 58 but we need to uplift this patch.
Finally, I'm not sure how to check this in automated tests. Therefore, this
patch doesn't include automated tests.
MozReview-Commit-ID: IaQBonoGawR
--HG--
extra : rebase_source : a89559932f27d98a02baf3e207c6be3c2a545aad
HTMLEditRules::MaybeSplitAncestorsForInsert() may be called with a point in a
text and it needs to return given split point as is. Additionally, the given
point may be in a text node. So, it may not be represented with an
nsCOMPtr<nsIContent>.
Therefore, we need to add new member, EditorDOMPoint, to SplitNodeResult and
when MaybeSplitAncestorsForInsert() needs to return the given point as is,
it should use it.
Note that if the methods which return SplitNodeResult split some nodes actually,
the left node and/or the right node may be removed from the DOM tree. In this
case, EditorDOMPoint cannot store such orphan node. Therefore, we cannot
make mNextNode nor mPreviousNode EditorDOMPoint.
MozReview-Commit-ID: LwH8RZzkrmT
--HG--
extra : rebase_source : a5ae2328bef3d887c0bf4e1b9c4a4247b93a4ac0
Now, we can make HTMLEditRules::SplitAsNeeded() use |SplitNodeResult| as its
result and |const EditorRawDOMPoint&| as specifying start of the deepest right
node. Then, the implementation becomes simpler.
And I think that we should rename it to MaybeSplitAncestorsForInsert().
Additionally, this patch makes it stop calling
EditorBase::IsDescendantOfEditorRoot() and HTMLEditor::GetActiveEditingHost()
because they are really expensive. Instead, it should check if the given start
point of the deepest right node is in active editing host before the loop and
if the loop reaches editing host.
MozReview-Commit-ID: KKpj5uyT2J
--HG--
extra : rebase_source : 0c9e9e9e28505b0fb5752e1cd4d42f64d22af3e7
In the following patch, we need to invalidate offset a lot of places after
splitting nodes. Therefore, there should be a helper stack class before that.
MozReview-Commit-ID: BgijAU7OizU
--HG--
extra : rebase_source : 520f29dacdffe5f7137ba7f11b289241b5fbface
First of all, this patches fixes a bug of EditorBase::CreateNode(). It takes
|EditorRawDOMPoint&| but it should be |const EditorRawDOMPoint&| for making
callers can specify temporary instances.
Next, this patch creates |SplitNodeResult| stack class for result of
EditorBase::SplitNodeDeep(). SplitNodeDeep() needs to return previous node
and next node of split point. They are called as left node and right node,
but these calls are really different term usage. Therefore, this patch names:
aOutLeftNode -> SplitNodeResult::GetPreviousNode()
aOutRightNode -> SplitNodeResult::GetNextNode()
and also declares SplitNodeResult::GetLeftNode() and
SplitNodeResult::GetRightNode() which are same meaning as left/right node of
other splitting methods.
Additionally, of course, this patch makes SplitNodeDeep() use
|const EditorRawDOMPoint&| to receive the start point of right node.
MozReview-Commit-ID: FnJpeKgtzm4
--HG--
extra : rebase_source : 3829e5528ef837b13fed305e0df1dbbf00e02a07
Make the loop in EditorBase::SplitNodeDeep() use EditorDOMPoint for making the
code simpler.
MozReview-Commit-ID: 3do3rWV4eIh
--HG--
extra : rebase_source : 480a5b5b133d8a735bda6ddec07e4edf9ef34035
Now, we can merge two if blocks in the loop of EditorBase::SplitNodeDeep() and
get rid of |didSplit| variable.
MozReview-Commit-ID: LJZHF6x2GLR
--HG--
extra : rebase_source : 5f58508f6fc0928236252670c85383a13200fc2c
This doesn't change any meaning of the loop.
It is a bug if the loop meets orphan node before meeting the most ancestor
node to be split which is given as aNode. So, we can check it before trying
to split it.
MozReview-Commit-ID: 1TD7WHCoZh1
--HG--
extra : rebase_source : 17b8d7b3db458e29fb52be5cedb900560e1b70a4
EmptyContainers::yes and EmptyContainers::no are not so clear name what they
mean.
They means whether NodeSplitDeep() creates or won't create empty nodes when
split point is at start edge or end edge of an element.
This patch renames them to SplitAtEdges::eDoNotCreateEmptyContainer and
SplitAtEdges::eAllowToCreateEmptyContainer and make
HTMLEditor::InsertNodeAtPoint() use it instead of an bool argument.
Additionally, the argument of NodeSplitDeep() is now not optional because
this difference is really important when you read around the callers.
MozReview-Commit-ID: 9hpMRkVDvCg
--HG--
extra : rebase_source : ee892361d66c9c9c5ed45ee9d3321474257ac417
Although, we need to make WSRunObject::PrepareToSplitAcrossBlocks() in
another bug, we should do it now for making HTMLEditRules::ReturnInParagraph()
implementation simpler.
MozReview-Commit-ID: AoMYqAEgCaV
--HG--
extra : rebase_source : cdfb16379f4ecab2a2694aeb283edd111fc81e95
nsIEditActionListner::DidSplitNode() takes 4 arguments, the right node,
old offset in the old right node before splitting, the new left node and
nsresult.
Computing offset for this doesn't make sense because it's always same as
the length of the left node. Additionally, nobody currently use nsersult.
So, we can get rid of it now.
Fortunately, nobody including comm-central and BlueGriffon implements
WillSplitNode(). So, we can get rid of it. However, removing interface
method should be done in a follow up bug. So, we can remove offset computation
in EditorBase::SplitNode() completely in the future.
MozReview-Commit-ID: JWj34SjBNJh
--HG--
extra : rebase_source : f0e1ed0e466dc8217c1a0ab1722790883a7efd1f
EditorBase::CreateTxnForSplitNode() and EditorBase::SplitNode() takes a set of
container and offset in it for specifying a point to split.
Instead, they should take EditorRawDOMPoint for specifying start of right node.
MozReview-Commit-ID: 5VwS8oudzIT
--HG--
extra : rebase_source : 727948e5cf95f0713019f57ae9a007b85569fa56
Make SplitNodeTransaction stores start of existing right node (which will be
split) instead of split point as a pair of the right node and offset in it.
MozReview-Commit-ID: 2DIpJGSuNaC
--HG--
extra : rebase_source : 13949bdddc30c59462e7fea7fadf29f015ab8d3a
EditorBaseSplitNodeImpl() should be clean up with EditorDOMPoint which should
be an argument to point the first point of right node (existing split node).
MozReview-Commit-ID: DN0yHm9G9yT
--HG--
extra : rebase_source : 256b4e2125e831b7be9e5c4aefc6f04c80e3c1f5
We hit assertion which were added by bug 1414713. That tells us an ancient bug.
There is comment which claims that we should move all list items in the right
list node to left list node if the list nodes should be merged. However, this
has never been done actually since 2002. The code tried to move *some* list
items in the right list node to the list list node. However, retrieving first
list item at an offset almost always failed because the offset variable has
never been initialized.
If we believe the comment, we should move all children of the right list node
to the left list node. However, until we get a testcase to reach this case,
we should keep current behavior, i.e., do nothing, for unexpected regression.
MozReview-Commit-ID: 1r81q1m44oW
--HG--
extra : rebase_source : fc02520f76440d5900fec0517aa6bcd188e1a14f
m-c, c-c and bluegriffon don't use this interface. So we should remove this.
MozReview-Commit-ID: 92VwGKlrOw5
--HG--
extra : rebase_source : 003763c6abc1406bcffabbffc3fe0696985ee97a
No one uses out parameter of InsertBR, so we should remove it. Also, CreateBR
has direction parameter for selection, so we should use it.
MozReview-Commit-ID: 8heqaXpR9He
--HG--
extra : rebase_source : 27b952f080a70fe039c9b43d7ae9f1394d4de01e
ReturnInListItem and ReturnInHeader uses Element as parameter, but
ReturnInParagraph doesn't use Element parameter even if it is Element.
So we should use Element for parameter.
MozReview-Commit-ID: 35JJTETFK45
--HG--
extra : rebase_source : aa101c921d176b7ae7807c461bca1c4a51f9aecc
libpref only allows pref modifications in the parent process. This patch
tightens up the checking, which is a bit inconsistent.
- It removes ENSURE_MAIN_PROCESS_WITH_WARNING, which does NS_WARNING on
failure, and replaces its uses with ENSURE_MAIN_PROCESS, which does NS_ERROR
on failure. This required adding an XRE_IsParentProcess() check to one place
in editor/.
- It converts XRE_IsContentProcess() tests to !XRE_IsParentProcess(), because
we now have multiple kinds of non-parent process.
- It uses ENSURE_MAIN_PROCESS to replace other checking code in a few places.
- It improves a comment in HandleDirty().
MozReview-Commit-ID: D8znQWH7ery
--HG--
extra : rebase_source : ea0fc095b31525bde82a1be217923512d030b76d
Now, we know HTMLEditRules::ReturnInParagraph() always splits the parent block
at start of selection. So, it doesn't need to receive the position from the
caller because the cost to get start of selection from first range of Selection
is really cheap.
MozReview-Commit-ID: EvNb6lUBLdt
--HG--
extra : rebase_source : 448fcb4e3a3c6df777825e8747839d6cd9ee2d56
The only caller of HTMLEditRules::ReturnInParagraph() is
HTMLEditRules::WillInsertBreak(). It should use EditorDOMPoint for storing
selection start.
Then, this patch makes what is set to ReturnInParagraph() clear. So, the
point ReturnInParagraph() is always start of selection.
MozReview-Commit-ID: 6X0P5gpwXKr
--HG--
extra : rebase_source : d1814e5b7c8e4005886607691b37fe6a83e8e5be
|selNode| and |selOffset| in HTMLEditRules::ReturnInParagraph() store the
point to split |aParentDivOrP|. So, they should be |containerAtSplitPoint|
and |offsetAtSplitPoint|.
Then, |newSelNode| can be renamed to |splitAfterNewBR|.
MozReview-Commit-ID: 1DcmLNx1Cff
--HG--
extra : rebase_source : 38e7e1ec68c060da3ea31f694243adc004eeece7
HTMLEditRules::ReturnInParagraph() stores point to insert new <br> element with
a set of |parent|, |node| and |offset|. Their names are really unclear and
they're really messy.
So, let's use new local variable, |EditorRawDOMPoint pointToInsertBR|. This is
set only when new <br> element is necessary. So, we can get rid of
|newBRneeded| too.
MozReview-Commit-ID: EdnhnlokurN
--HG--
extra : rebase_source : d97a985d71a7b4552ccdeedde55f8b7fcb0be590
This cleans up |aSelection| and |aPara| of HTMLEditRules::ReturnInParagraph().
|aSelection| should be reference for avoiding nullptr check.
|aPara| is so too. Additionally, the name is not clear. We should rename it
to |aParentDivOrP| because it's a block parent of the point and has to be
<div> or <p> element.
MozReview-Commit-ID: 8LbKGlrvaIj
--HG--
extra : rebase_source : e0593c916791ec5b39b4138e21b6ce8c680dc4d8
The local variable |sibling| in HTMLEditRules::ReturnInParagraph() is set to
aBRNode of SplitParagraph(). So, the name should be renamed to |brNode|.
Then, the |brNode| should be cleared if it's not a <br> node actually. However,
SplitParagraph() doesn't allow aBRNode to be nullptr. aBRNode is only used to
remove it from the document if it's not necessary. So, it should be able to be
nullptr. Therefore, this patch changes SplitParagraph() too.
Note that SplitParagrah() is called only by ReturnInParagraph(). So, we don't
need to worry about other callers.
MozReview-Commit-ID: 7Ynk9m5F8Mi
--HG--
extra : rebase_source : e2583c70ad274fe74f48df687796ed71a66bdf98
For reducing the number of arguments of HTMLEditRules::ReturnInParagraph(),
let's make it return EditActionResult and get rid of |aCancel| and |aHandled|.
MozReview-Commit-ID: HU1SthEjonn
--HG--
extra : rebase_source : 072865996aaccc63924c34f91014b41b64aa1a16
EditorBase::CreateNode() should take EditorRawDOMPoint as insertion point of
the new element instead of a set of container, child and offset of the child
in the container.
This patch initializes EditorRawDOMPoint with original 3 arguments as far as
possible. If the relation of them are broken, MOZ_ASSERT in RawRangeBoundary
constructor detects existing bugs.
MozReview-Commit-ID: 2N55S6pRv7k
--HG--
extra : rebase_source : 2b14a7715815ca0007635b8f791ca9edbe5b65f1
nsIEditActionListener::WillCreateElement() and
nsIEditActionListener::DidCreateElement() are implemented only by m-c.
So, we can remove a set of container node and offset in it from their argument.
Instead, WillCreateElement() should take a node which will be next sibling of
the new node.
Note that only implementation of them is, HTMLEditRules::DidCreateElement().
So, we can get rid of them and can call HTMLEditRules::DidCreateElement()
directly from EditorBase::CreateNode(). However, such change should be done
in another bug which checks all nsIEditActionListener method implementations.
MozReview-Commit-ID: 4LQEs2WwrVC
--HG--
extra : rebase_source : ee1bee1413c578b2873a291c712b8ef46221db0f
The constructor of CreateElementTransaction now takes EditorRawDOMPoint instead
of a set of container node and offset in it. So, its only user,
EditorBase::CreateTxnForCreateElement(), should take EditorRawDOMPoint too.
MozReview-Commit-ID: A8QfPM3LRii
--HG--
extra : rebase_source : 4a99e5cb58230649d19faca788a330fe02eb6bb1
The constructor of CreateElementTransaction should use EditorRawDOMPoint to
receive insertion point of the new element. Then, it should be stored with
RangeBoundary. With this change, CreateElementTransaction doesn't need to
compute child node at insertion point.
Additionally, this creates InsertNode() method. Current code works differently
when DoTransaction() is called and RedoTransaction() is called.
MozReview-Commit-ID: 8ujhmzn65Wg
--HG--
extra : rebase_source : 30cc045a30a3836f211d11e5f70a85804f44a72a
By the fix of bug 1407352, DeleteRangeTransaction::CreateTxnsToDeleteBetween()
starts to use child node instead of a set of container node and offset in it.
However, this is ugly and using RawRangeBoundary may reduce computing offset
more. So, they should use RawRangeBoundary to refer delete points.
MozReview-Commit-ID: pwDHOxpz0E
--HG--
extra : rebase_source : 3871ba4fa3cfb174d5dac57822ae69c40a305323
In some places, editor computes index from child node for collapsing selection
at the child node. However, it's expensive. Therefore, editor should use
Selection::Collapse(const RawRangeBoundary&) as far as possible.
MozReview-Commit-ID: LF2MwASuXzZ
--HG--
extra : rebase_source : b7afc35c0d9d88845391b6f18de57cbff1935ae4
Bug 1402904 added nullptr check for parent node, but I forgot to add this
nullptr check of selected node for outdent command.
So I need to add more nullptr check.
MozReview-Commit-ID: Au9wrG6htk8
--HG--
extra : rebase_source : bd73b1b667b6dc869ebcea3fdfbe1eb3b04a8cde
EditorUtils::IsDescendantOf() current takes a pointer to offset or a pointer to
child content if the caller needs to know the child of the most ancestor node.
However, some callers should get a child as EditorDOMPoint or EditorRawDOMPoint.
Then, they can be used for some editor methods which need to take child node
for performance optimization.
This patch makes EditorUtils::IsDescendantOf() as only two overloads. One takes
pointer to EditorRawDOMPoint as optional out argument. The other takes pointer
to EditorDOMPoint as an out param.
Additionally, this creates new constructor of AutoTrackDOMPoint for making it
can treat EditorDOMPoint directly.
MozReview-Commit-ID: IsAGTUvKI19
--HG--
extra : rebase_source : 97469a21b974c6a1dd515ab472bbc4a88c1899c8
RangeBoundaryBase shouldn't compute mRef when it's initialized with offset.
E.g., some users of the template class may initialize it with a container and
offset in it but it may not refer mRef or may refer after modifying offset.
On the other hand, RangeBoundaryBase::InvalidateOffset() is a special method.
It assumes that mRef is always initialized when it's called but can be
invalidate mOffset until retrieved actually. This is necessary for
nsRange::mStart and nsRange::mEnd since the offset may be changed when
some nodes are inserted before the referring node.
So, now, InvalidateOffset() should be a protected method and make nsRange a
friend class of RangeBoundaryBase. Then, when nsRange sets mStart and/or mEnd,
nsRange itself should guarantee that their mRefs are initialized.
MozReview-Commit-ID: Alr4YkDXIND
--HG--
extra : rebase_source : 7e6828374db7989ae91b9e485571ec553f7435af
A lot of methods in editor returns a child offset with an out param when it
returns its container and offset in the container. This is ugly hack for
performance of nsINode::IndexOf(). However, there are a lot of regression
since the relation between offset and child node can be broken really easily.
So, we should make EditorDOMPoint as a subclass of RangeBoundary and manage
a set of container, reference child and its offset in it (e.g.,
SetNextSibling() added by this patch).
Note that RangeBoundary's performance is not good for temporary use if we set
a point with offset, it immediately retrieves mRef. The following patch will
improve this performance.
MozReview-Commit-ID: 7mcJ1P1OjVr
--HG--
rename : editor/libeditor/EditorUtils.h => editor/libeditor/EditorDOMPoint.h
extra : rebase_source : 785094fcfc592d9e5b48cbc36ed225dbb8bb4111
HTMLEditRules::BustUpInlinesAtRangeEndpoints() tries to split all inline nodes
at range start and range end. It uses EditorBase::SplitNodeDeep() to split
the nodes and HTMLEditRules::GetHighestInlineParent() to retrieve the highest
inline parent of them.
Currently, HTMLEditRules::GetHighestInlineParent() may return editing host or
ancestor of it if active editing host is not block. Then, it may cause
splitting editing host or its parents and following methods of HTMLEditRules
will fail to modify the nodes created outside the editing host.
So, HTMLEditRules::GetHighestInlineParent() should return only one of the
descendants of active editing host.
Unfortunately, even if just adding the test case as a crash test, I cannot
reproduce the crash with automated tests. Therefore, this patch doesn't
include any automated tests.
And this patch changes a crash test, 1402196.html, which expects that an inline
editing host is split by execCommand("insertOrderedList"). However, this patch
fixes this wrong behavior. Therefore, this patch changes the event target of
event listener from <p> inside the editing host to the editing host itself.
MozReview-Commit-ID: 8i5ci1fcrDd
--HG--
extra : rebase_source : 572a7b22550a38ca71c954f62eefa695addd53c2
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
Currently, HTMLEditRules::WillInsertBreak() checks if the editing host can
contain a <p> element as a child or a descendant. However, this is not enough.
If an inline element has a block element which can contain a <p> element,
current implementation considers to insert a <br>. This is possible when
* The editing host is an unknown element including user defined element.
* The editing host is an inline element and its children and/or descendants
were added by JS. E.g., <span contenteditable> element can have <div>
element.
I think that we should consider to insert a <br> element when:
- There is no block ancestors in the editing host.
- The editing host is the only block element and it cannot contain <p> element
or the default paragraph separator is <br> element.
- The nearest block ancestor isn't a single-line container declared in the
execCommand spec and there are no block elements which can contain <p>
element.
Note that Chromium checks if CSS box of ancestors is block too. However,
it must be out of scope of this bug.
MozReview-Commit-ID: HdjU9t83Nd1
--HG--
extra : rebase_source : 7030671268a610613359b5d8ae5d126e120f59bd
Perhaps, most callers don't need parent block outside active editing host.
Therefore, callers of these methods should be able to specify the editing
host for making those methods stop looking for a block ancestor.
Then, callers can avoid using EditorUtils::IsDescendantOf() and
nsContentUtils::IsContentDescendantOf().
MozReview-Commit-ID: 7IK4gAVHY5d
--HG--
extra : rebase_source : 31cd55026f0ce005d906499de4ebe5d1c39555e9
Currently, HTMLEditor::GetBlockNodeParent(nsIDOMNode*) is used only by
HTMLEditor::DoInsertHTMLWithContext() and there is a variable of nsINode*.
So, we don't need to keep it anymore.
MozReview-Commit-ID: LEWaiR5BEB9
--HG--
extra : rebase_source : 64ef772f3b7883bd4aae48dec737663e6036553b
SetAttributeOrEquivalent can remove CSS property that is same behaviour by
part 2. So we should use it instead of SetAttribute.
MozReview-Commit-ID: InCZQVdbDRm
--HG--
extra : rebase_source : d746b07bcfffc752ad90b9e1504e2f0afc23d457
SetAttributeOrEquivalent sets element's attribute when
HTMLEditor::IsCSSEnabled() is false. It should remove the CSS property that is
same behaviour too.
MozReview-Commit-ID: ChKjlB7wI0Z
--HG--
extra : rebase_source : c31b940394750757b2393a6876534590410d9398
Actually, we don't consider CSS property to get alignment when IsCSSEnabled()
is false. For WebKit and Blink compatibility, we should consider this situation.
MozReview-Commit-ID: 9ORntUmbIbf
--HG--
extra : rebase_source : 21d27f34cf1331bd2fee097c5c445dc16c453d4e
This requires exposing the reftest chrome package to content, but that should be
OK, and this seems to work...
MozReview-Commit-ID: EWkwqTHW3dg
--HG--
extra : rebase_source : 12cabe4389375ac4c3abd0a9327baf268aab7c1a
WSRunObject::InsertText() may delete given child node at offset with calling
DeleteChars() or CheckLeadingNBSP() before calling HTMLEditor::InsertTextImpl().
Therefore, even though using nsINode::GetChildAt() is slow, it needs to update
aInOutChildAtOffset after calling them.
MozReview-Commit-ID: AbTTfNAjMIK
--HG--
extra : rebase_source : b4282e8dc6e395acc89d7c155bfeae46e7c41e4a
The bug is a report for hitting MOZ_ASSERT, but we should also check the result
of the call of execCommand.
MozReview-Commit-ID: FydZKAjI2Rl
--HG--
extra : rebase_source : 327988cea366474cbe659a3b80c09ce7ceef0005
RangeItem::GetRange can return null, so we shouldn't add null range to
aArrayOfRanges.
MozReview-Commit-ID: Ci5VHeqE8km
--HG--
extra : rebase_source : 83abb5f4ea405c360e63b7ed73530a7321a2a1e5
RangeItem::GetRange can return null, so we shouldn't add null range to
aArrayOfRanges.
MozReview-Commit-ID: Ci5VHeqE8km
--HG--
extra : rebase_source : 34f5e98de680ffe588d64244592f775450ce98cf
This crash test can cause crash before landing the patches for bug 1415509.
So, let's take this for regression test.
MozReview-Commit-ID: 652wi49e720
--HG--
extra : rebase_source : a7a897670220e4f14df91c4093e65aa7da7f6015
First, the method name is not correct. It tries to find an editable node near
the given DOM point. Therefore, it should be FindNearEditableNode().
Next, the implementation did something odd. E.g., in the first |if| block,
when |nearNode| is nullptr, it returns nullptr. However, following |if| block
does something only when |nearNode| is nullptr. So, we can get rid of the
second |if| block. Then, nobody will change aDirection. So, we can make it
not a reference now.
Similarly, in |while| block, if |nearNode| becomes nullptr, it returns error.
However, following block checks if |nearNode| is NOT nullptr. So, we can get
rid of this |if| statement and outdent its block.
Additionally, |curNode| isn't necessary. It only increments the refcount
redundantly. So, we can get rid of it.
Finally, FindNearEditableNode() can return found node directly instead of
error code because error code doesn't make sense. Not found an editable
node is not illegal. And also it can take EditorRawDOMPoint instead of
a set of container, child and offset of the child in the container.
MozReview-Commit-ID: CTI581PhJMd
--HG--
extra : rebase_source : 7e05998721ce96727d40dda1be5e7e36b090bcd3
HTMLEditor::GetNextHTMLNode() should be redesigned as
HTMLEditor::GetNextEditableHTMLNode(nsINode&),
HTMLEditor::GetNextEditableHTMLNodeInBlock(nsINode&),
HTMLEditor::GetNextEditableHTMLNode(const EditorRawDOMPoint&) and
HTMLEditor::GetNextEditableHTMLNodeInBlock(const EditorRawDOMPoint&).
Same as GetPreviousEditableHTMLNode*(), we don't need the methods to find
non-editable nodes too.
MozReview-Commit-ID: JjZauCMblp4
--HG--
extra : rebase_source : 1e650d79bc21d7f920b3f46f4a2f208ac23cc0a6
HTMLEditor::GetPriorHTMLNode() methods are similar to EditorBase::GetPriorNode()
which was redesigned with the previous patch.
So, it should be redesigned as
HTMLEditor::GetPreviousEditableHTMLNode(nsINode&),
HTMLEditor::GetPreviousEditableHTMLNode(const EditorRawDOMPoint&),
HTMLEditor::GetPreviousEditableHTMLNodeInBlock(nsINode&) and
HTMLEditor::GetPreviousEditableHTMLNodeInBlock(const EditorRawDOMPoint&).
Note that HTMLEditor::GetPriorHTMLNode() are always return editable node.
So, we don't need to create non-editable node methods for them.
Although, I don't like the word "HTMLNode" because this can return SVG element
or something too. The additional feature of those methods is just checking
given node is in active editing host. So, they are for HTML editor, but not
returning only HTML nodes. However, I have no better idea with shorter name.
MozReview-Commit-ID: 3J4IaBOFjzj
--HG--
extra : rebase_source : 712bc8676fcdc37f38fd46083df177c0fe6bd408
An overload of EditorBase::GetNextNode() takes a set of container, child node
and offset of the child in the container. Replacing it with EditorRawDOMPoint
makes the caller simpler.
Additionally, it has two bool arguments, one is for searching if editable node,
the other is for searching if in same block. So, they can be hidden with
some human readable inline methods.
When I was creating this patch, I realized that
GetNextNodeInternal(const EditorRawDOMPoint& aPoint) may return
aPoint.GetChildAtOffset(). I.e., it starts to search from the specified point
rather than next node. On the other hand, GetNextNodeInternal(nsINode& aNode)
never returns aNode itself. So, it there is better name instead of "Next",
we should take it. But I have no better idea. So, this patch just explains
the difference with comments in EditorBase.h.
MozReview-Commit-ID: 4Lb6o9SJuhy
--HG--
extra : rebase_source : d20d728eae69659ef448b6679ae8f73d64c2d7e9
An overload of EditorBase::GetPriorNode() takes a set of container, child node
and offset of the child in the container. Replacing it with EditorRawDOMPoint
makes the caller simpler.
Additionally, it has two bool arguments, one is for searching if editable node,
the other is for searching if in same block. So, they can be hidden with
some human readable inline methods.
Finally, "Prior" isn't a term of DOM. So, let's use "Previous" instead.
MozReview-Commit-ID: A9uKzHaikY9
--HG--
extra : rebase_source : 15bfdfde0ad89a5331d6c8a24351741eeef476d5
Like EditorBase::InsertTextImpl(), WSRunObject::InsertText() is really messy.
So, it should take same arguments as EditorBase::InsertTextImpl().
MozReview-Commit-ID: 5uKGaxKheRv
--HG--
extra : rebase_source : 49ce0eb7ea25b397b6b1a19f1bc21d711740c043
EditorBase::InsertTextImpl() takes |nsCOMPtr<nsINode>*|, |nsCOMPtr<nsIContent>*|
and |int32_t| as in/out arguments for container, child and offset of the child
in the container. But this makes the callers really hard to read and ugly.
So, we should make the method take |const EditorRawDOMPoint&| argument as input
and |EditorRawDOMPoint*| as out argument.
MozReview-Commit-ID: 2ijIfGl4Zo7
--HG--
extra : rebase_source : b309d9bdc04aac620f138769ba18ad7e4597fe6c
EditorBase::FindBetterInsertionPoint() now use 3 in/out arguments. This is
really ugly and making the callers hard to read. So, let's make it take an
argument whose type is |const EditorRawDOMPoint&| and return other
EditorRawDOMPoint instance.
Additionally, this fixes bugs of text node length checks in the method.
Basically, this shouldn't affect to any actual behavior, though. That is
because text node shouldn't be able to have string longer than INT32_MAX.
MozReview-Commit-ID: FClUQSJzd8c
--HG--
extra : rebase_source : 3e2fbd345015f7068c7e35a94c31731e7936009f
It is no reason to use custom atom instead of nsGkAtoms now, so we should
use nsGkAtoms instead.
MozReview-Commit-ID: 9slsZtLDNKH
--HG--
extra : histedit_source : 8ad70ff1adfa145bc0e8da3c6f43f3dba9b558f1
There are four things that must be provided for every static atom, two of which
have a macro:
- the atom pointer declaration (no macro);
- the atom pointer definition (no macro);
- the atom char buffer (NS_STATIC_ATOM_BUFFER);
- the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP).
This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL
and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros
to make them easier to use (e.g. all the '##' concatenation now happens within
the macros).
One consequence of the change is that all static atoms must be within a class,
so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms).
The patch also adds a big comment explaining how the macros are used, and what
their expansion looks like. This makes it a lot easier to understand how static
atoms work. Correspondingly, the patch removes some small comments scattered
around the macro use points.
MozReview-Commit-ID: wpRyrEOTHE
--HG--
extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
Because it's the type we use to set up static atoms at startup, not the static
atom itself.
The patch accordingly renames some parameters, variables, and NS_STATIC_ATOM,
for consistency.
MozReview-Commit-ID: 1a0KvhYNNw2
--HG--
extra : rebase_source : 5c66e5b2dfe053a368bf3584d957198aec4cce91
Since if the container is not a container node like a text node or the offset
is same as the length, child at the offset can be nullptr.
MozReview-Commit-ID: DCnFwUjNgk7
--HG--
extra : rebase_source : 48823390645d79db391dcaf64dab59e754b680a5
|selChild| should be a node which is at |curOffset| in |curNode|, however,
it's not updated when |curOffset| is updated by a call of CreateBRImpl(). So,
it should be next sibling of the created br node.
MozReview-Commit-ID: IVfTjVMp3lB
--HG--
extra : rebase_source : fbc355e3c0425a495c78c3c028308dac26617283
Editor sometimes extracts atom to string to compare element name.
It is unnecessary to use atom directly.
MozReview-Commit-ID: FEvyiIeaozs
--HG--
extra : rebase_source : 4418d0c82fa4fedd814b914f2cf3a86d74ad9835
Masayuki Nakano
Boris Zbarsky
Makoto Kato
Adrian Wielgosik
Chris Peterson
Cameron McCormack
Olli Pettay
Margareta Eliza Balazs
Dão Gottwald
Andrea Marchesini
Emilio Cobos Álvarez
Cosmin Sabou
Jonathan Kew
Sylvestre Ledru
Neil Deakin
Brindusan Cristian
Edgar Chen
Bogdan Tara
Nicholas Nethercote
Ryan VanderMeulen
Kyle Machulis
Narcis Beleuzu
Phil Ringnalda
Xidorn Quan
Sebastian Hengst
Nika Layzell
Marco Castelluccio
Masatoshi Kimura
Jason Kratzer
Kris Maglione
Ehsan Akhgari