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
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
Masayuki Nakano
Narcis Beleuzu
Makoto Kato
Margareta Eliza Balazs
Boris Zbarsky
Dão Gottwald
Phil Ringnalda
Xidorn Quan
Sebastian Hengst
Nika Layzell
Marco Castelluccio
Chris Peterson
Emilio Cobos Álvarez