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
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