nsXPIDLStrings are marked as VOIDED upon initialization. Most of these local
nsXPIDLString variables are immediately set via getter_Copies(), which will
either assign a string value (using Adopt()) or do SetIsVoid(). These can be
trivially converted to nsString, which will get the same treatment.
The patch suitably converts the remaining nsXPIDLString local variable as well.
--HG--
extra : rebase_source : 5fff9f2c6844559198f601853f8db08564add7d5
CreateAnonymousElement still uses nsIDOMNode, but we should use nsIContent for it.
MozReview-Commit-ID: 2xgzlE6NVra
--HG--
extra : rebase_source : c93a9acb230604da391f705b0038e3cf7fbd4f23
This method can be extremely hot, so we need to remove all sources of XPCOM
overhead from it. This includes the usages of weak pointers (thanks to the
previous parts), refcounting, and QueryInterface.
I kept the callers hold the selection controller alive by assigning the
return value to an nsCOMPtr in places where the methods called on it could
have a remote chance of messing with the lifetime of objects.
Besides some unnecessary copying and malloc overhead that this removes, it
also removes a call to dom::Text::GetData() which we used to only make to
get the old length of the text node before modifying it. Turns out that
this old length was already obtained once in SetTextImpl().
Currently, HTMLEditRules::SplitParagraph() inserts moz-<br> element when split element and/or new element causes empty line. However, PlaintextSerializer ignores moz-<br> elements. Therefore, empty lines which are created by SplitParagraph() will be removed when it's converted to plaintext.
So, it should insert normal <br> element for placeholder of empty lines instead. Note that moz-<br> elements are appeared as normal <br> elements in the result of Element.innerHTML. Additionally, Chromium always inserts a <br> element for empty block elements which are created by Enter key press. Therefore, using normal <br> element in this case shouldn't cause any compatibility problems.
MozReview-Commit-ID: FNV41zEFWqQ
--HG--
extra : rebase_source : ece6c2e275e2a75d9d2871d62ed4204115792b99
After reframe, SetSelectionAfterTableEdit might be called from RAII class, so we should check whether editor is destroyed.
MozReview-Commit-ID: I4r6kvxgRDZ
--HG--
extra : rebase_source : 4bd71775f02f57573af0f0efd5c1946285e4e4f4
HTMLEditor::TabInTable inserts row element, then it selects a cell. But when enabling lazy frame construction for editable node, it selects invalid cell and table.
Because HTMLEditor::SetSelectionAfterTableEdit doesn't select cell correctly on InsertTableRow().
HTMLEditor::SetSelectionAfterTableEdit uses HTMLEditor::GetCellAt, so it depends on frame. So we need flush frame before calling it.
Also, a comment of HTMLEditor::InsertTableRow is invalid now because we don't use nsresult version of CreateElementWithDefualts.
MozReview-Commit-ID: 698TvmMZgwB
--HG--
extra : rebase_source : 95df12f1f870a2c68d02b24b8758dfe6d381a416
This makes the SetTextTransaction transaction behave more similarly to the rest of
the editor transactions, by making sure the inner transactions don't manipulate
the selections themselves and leave it up to the AfterEdit() method to take care of
adjusting the selection when the entire editing operation is finished.
test_bug795418-*.html depends on clipboard. But these tests aren't subsuite=clipboard and are sometimes failure (bug 1334700, bug 1335221, bug 1339430, bug 1343883 and bug 1348093). So we should move these to subsuite=clipboard to try fixing this.
MozReview-Commit-ID: 1m5dFGZ18a
--HG--
extra : rebase_source : 847b1b7842c32e93c61b8ee572cff16c70adc323
nsIDocument::AdoptNode might to remove all properties. So before destroying editor, NAC property might be already removed. So we have to consider that NAC is removed.
MozReview-Commit-ID: DakRRqrzEtF
--HG--
extra : rebase_source : ce972f1b42b6ff7efdf09b9a70cc1a9d27f128fb
I've been having problems with interdiffs on mozreview lately, so for
ease of review, this patch is being submitted as a seperate patch for
review. Once it is r+'d, it will be folded into the first patch in
this set before landing.
MozReview-Commit-ID: CS9MngaXlBd
--HG--
extra : rebase_source : 6a86fd4f7a66e73497a756976a2562d183002a2a
