SplitNodeDeepWithTransaction will split nodes until better point. But
this test case becomes that node is orphan into loop. So I would like to
add more check whether parent is nothing.
MozReview-Commit-ID: EroSV4uVBVL
--HG--
extra : rebase_source : f594bdf7cd9efac7d10e6e05a8f87dadfc761295
This crash is that HTMLEditor::ClearStyle returns nullptr for aNode even if
successful.
When current start node and offset isn't within ancestor limiter,
HTMLEditor::ClearStyle will return nullptr for split node even if successful.
Because SplitNodeTransation returns error since Selection::Collapse is failed.
Then, SplitNodeDeep in HTMLEditor::SplitStyleAvovePoint returns error. But
this error is ignored. So node will becomes null even if successful.
CreateStyleForInsertText will set new selection when there is split node, so
we shouldn't set selection on ClearStyle.
Also, InsertNodeTransation is ignored for error when Collapse is failed, but
SplitNodeTransaction isn't ignored. We should create a rule when collapse is
failed on transaction.
And at feature, we shouldn't set selection in CreateStyleForInsertText, and
then, it should return new insertion point for InsertText instead of setting
new selection.
MozReview-Commit-ID: BRKWLqTfrvC
--HG--
extra : rebase_source : 2cd025e9d40688f643a843b39512dccc2bb7c4a2
When calling UninitSpellChecker during calling UpdateDictionary, this crash
occurs. Since Thunderbird calls UninitSpellChecker by [Recheck Text] button,
this only occurs on Thunderbird.
After calling UninitSpellChecker, we should not update dictionary.
MozReview-Commit-ID: K4SPJ5FDo8n
--HG--
extra : rebase_source : d760c6472f56cef520c399e8c1f20536c3a22e36
When calling UninitSpellChecker during calling UpdateDictionary, this crash
occurs. Since Thunderbird calls UninitSpellChecker by [Recheck Text] button,
this only occurs on Thunderbird.
After calling UninitSpellChecker, we should not update dictionary.
MozReview-Commit-ID: K4SPJ5FDo8n
--HG--
extra : rebase_source : 67fa439e2a4767502ca84095754150d513a939b2
extra : amend_source : 1b065ebe275cefc02809478eb7d6d807f19dbbee
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
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
1405747.html is kind of same issue. But when editing 1405747.html, the crash doesn't occur. So I keep original HTML by jsfuzzy.
MozReview-Commit-ID: 9BcUkWeBlr5
--HG--
extra : rebase_source : 1bac60293d3b4997a380cf625c6492db22f60160
extra : histedit_source : eae38e2d69e0705545acf1ef1f2d04e7977b8899
When parent node of selected node is null, crash might occur in GetCSSBackgroundColorState. So when parent is null, we should return default value. In this situation, Edge and Blink don't throw error, Gecko shouldn't return error too.
MozReview-Commit-ID: 5C6jSAFkCso
--HG--
extra : rebase_source : 0185f9fb5fde92eee5611e6bb95e8676c10b135c
When we turn on the pref security.data_uri.unique_opaque_origin to make
data URI is unique origin, the following tests will fail because now
data document is treated as cross origin, so we replace data URIs with
seperate files, hence it will still in the same origin.
Add minimal crash test for this. When removing a line, this doesn't occur.
MozReview-Commit-ID: JqS2E8q47ML
--HG--
extra : rebase_source : 322a77cbc49e29bbd6b705650485634dd4801b8b
Although this crash doesn't occur after landing bug 1369140, we should add this test to crashtest.
MozReview-Commit-ID: mRm4P876zg
--HG--
extra : rebase_source : 9a85c8ba3a5652000512d165b82df9aa2c8176e1
