Additionally, it creates AutoSelectionRestorer. So, this patch adds
CanHandleEditAction() check after its caller since even if it returns
NS_OK, the editor might have been gone.
MozReview-Commit-ID: BgIbpHFFPE1
--HG--
extra : rebase_source : 010befdb34f8269f6f7fc24d1ae13eba4575aa69
And this patch creates a new method, OutdentAroundSelection(), to check if
restoring Selection with AutoSelectionRestorer causes destroying the editor.
However, this does NOT change any logic in the new method except changing some
else-if blocks to if blocks with early-return style.
MozReview-Commit-ID: JMIo4kUOkwx
--HG--
extra : rebase_source : 0d628ebb866d7b63f8b78e6d701c27378a82dfb6
And this patch renames it to SplitRangeOffFromBlockAndRemoveMiddleContainer()
for making the name explain what it does.
MozReview-Commit-ID: 546dnCeoGOV
--HG--
extra : rebase_source : 7f0762cfa377a07d28342a1092ad0a7ee70fa108
And this patch renames it to SplitRangeOffFromBlock() for making the name
explain what it does since "split" is used as splitting to two nodes widely
in editor.
MozReview-Commit-ID: GrRu5sI4yrP
--HG--
extra : rebase_source : 3ec27bce3769af518d3f1c317559fd89d379c539
Additionally, this patch renames it to MaybeDeleteTopMostEmptyAncestor() for
making its name explain what it does.
MozReview-Commit-ID: 1i7zeq9In2T
--HG--
extra : rebase_source : 8d9de9e6154038a993be636c3cedf950a6efd179
PromoteRange() related methods do not change Selection nor the DOM tree.
Therefore, they must be safe. However, only PromoteRange() takes an nsRange
instance and modifies it. If it's in Selection, that causes selectionchange
event. Therefore, we should check if given range is in Selection with
MOZ_ASSERT().
MozReview-Commit-ID: AXkmHFB4P08
--HG--
extra : rebase_source : 539b39d0217a7dc06f76e70546096d30b2734c02
Despite of the name of GetNodesForOperation() and related methods, it changes
the DOM tree if their aTouchContent is TouchContent::yes (by default).
Therefore, they should return NS_ERROR_EDITOR_DESTROYED if they cause destroying
the editor and all callers should check the result. Therefore, this patch mark
them as MOZ_MUST_USE.
Additionally, because of importance of aTouchContent, this patch makes the
arguments not optional. This change must make other developers being careful
to use them. (Although TouchContent does not feel dangerous. We should rename
it to make its risk clearer.)
On the other hand, this patch removes aTouchContent from
GetParagraphFormatNodes() since it's always called with TouchContent::no.
Therefore, this method is always safe.
Although I tried to document those methods, but I have not understood them
completely yet. Perhaps, we should redesign them in another bug both to
learn them and making them faster and simpler.
MozReview-Commit-ID: 4vknJGUdwEe
--HG--
extra : rebase_source : 486949005283548697e6eeb7175f6189a66defaa
Unfortunately, we need to make it take out argument for returning new first
child point of right node. If we can create JoinNodesResult which have
nsresult and EditorDOMPoint, we can avoid that, but EditorBase::JoinNodes()
does not want it. So, even if we create such class, only 2 callers of the
methods are its users...
MozReview-Commit-ID: 1zwVZ0FriwN
--HG--
extra : rebase_source : 1f7867774f9a30bec78596b0282717435e7223c0
And this patch renames it to
InsertBRElementToEmptyListItemsAndTableCellsInChangedRange().
MozReview-Commit-ID: 1DGhcI93YAk
--HG--
extra : rebase_source : caa675a5b02c18e9ca57171294bdaf48e7563dc0
And this patch renames it to RemoveEmptyNodesInChangedRange().
MozReview-Commit-ID: Kr2xmUOH1ZZ
--HG--
extra : rebase_source : 59a0a70360c6e0d426c329f4be757c2c0eac96c4
Additionally, this patch renames its specific enum class from ContentsOnly
to ResetAlignOf for making its target clearer.
MozReview-Commit-ID: KD4ndAsMClN
--HG--
extra : rebase_source : 302598397cf32893c7db18a6a014d0db862cb8f6
Additionally, this patch renames it to ChangeMarginStart() for making its
job clearer and add two inline wrapper methods.
MozReview-Commit-ID: L2GfLKhT6sa
--HG--
extra : rebase_source : d1d293f742214048ce5dfbbb7ebd50b0cbeed881
This patch also makes aCancel of TextEditRules::WillInsert() optional since
a lot of callers need to ignore the result.
MozReview-Commit-ID: JrvycxMQ9Mm
--HG--
extra : rebase_source : 9ecdc0fd363d9da33c12409f2993da9c58553598
This patch creates internal method for it as DeleteSelectionWithTransaction()
because it needs to create SelectionBatcher and destruction of it may cause
destroying the editor. Therefore, unfortunately, all callers of
DeleteSelectionWithTransaction() needs to check CanHandleEditAction()
manually. If we could use try-catch, we could make it safer, though.
MozReview-Commit-ID: 13enOQjEzNn
--HG--
extra : rebase_source : 5a902026bcc507fbf9f1949fdcf33a98aabd9a0b
And also this patch removes unnecessary arguments from the method.
MozReview-Commit-ID: UKscK4vFVX
--HG--
extra : rebase_source : 7f6b9405824a3f175f165a2d7d75a293108278f3
Note that HTMLEditRules::DocumentModifiedWorker() is a runnable method.
So, it cannot return nsresult. Therefore, it just checks the result
only with NS_WARNING_ASSERTION().
MozReview-Commit-ID: KBSpv5H5KGU
--HG--
extra : rebase_source : b356ab04d0459214df9dbb3dbfb0e3eecc686348
And also this patch marks it as MOZ_MUST_USE. All callers have to check if
the result is NS_ERROR_EDITOR_DESTROYED at least.
MozReview-Commit-ID: H4DfU1asPpe
--HG--
extra : rebase_source : c11cc00500aad44bd542147fb971e3cce4d634e2
First, this patch changes TextEditRules::CreateBRInternal() to a private method
for making any callers use CreateBR() or CreateMozBR() instead.
Then, this patch makes TextEditRules::CreateBRInternal() return both nsresult
and created <br> element with CreateElementResult class.
Finally, this patch makes all callers of them check if they don't return an
error code including NS_ERROR_EDITOR_DESTROYED.
MozReview-Commit-ID: 18OvPmbDVHK
--HG--
extra : rebase_source : 328a91146539763cec317105b92aa3ce5d4b8233
This patch defines NS_ERROR_EDITOR_DESTROYED error code as an editor module
specific error code.
And creates TextEditRules::CanHandleEditAction() to check if the instance
can keep handling edit action.
MozReview-Commit-ID: 4qECwNBO0yz
--HG--
extra : rebase_source : a925a9b6840d4d06e2792b9fe276e062288b0806
Now RulesInfo uses nsAString, but old comment is "XXX Struct should store
a nsAReadable*". We can remove unnecessary local variable of nsString.
MozReview-Commit-ID: C7gnTG7xTjU
--HG--
extra : rebase_source : e141bbcefd75d90b836668f710350d4362d66c76
CanPasteTransferable and PreDestroy aren't used from script (inc. comm-central
and bluegriffon), so we should move these to out of nsIEditor.
MozReview-Commit-ID: GRfBobAm2qi
--HG--
extra : rebase_source : 812792ff43da24bfd9cb99c4b3127e6acdc43ba1
Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
Some Did*() of TextEditRules and HTMLEditRules do nothing except returning
NS_OK. Let's remove them since there is no reason to keep them.
MozReview-Commit-ID: Jcdh5rnm5Yc
--HG--
extra : rebase_source : 54aedd8187edfa244bc8fbe8f560fb6ee064e9cf
Now, each protected/private method of TextEditRules and HTMLEditRules can
retrieve Selection instance safely and quickly. Therefore, their pointer or
reference of Selection arguments are not necessary. Therefore, this patch
removes them.
MozReview-Commit-ID: 1SPmKXmd7kz
--HG--
extra : rebase_source : 32dfd2d5e8b0667318a5b3766a8a7d8594bba8e7
After this patch applies, most methods of TextEditRules and HTMLEditRules
don't need to take Selection as their arguments. Therefore, next patch will
remove them.
MozReview-Commit-ID: 99r3ZkfG2In
--HG--
extra : rebase_source : 8666ded8f2e6954f2e3cf6bb1ba1cf3313f65e70
Although, this patch removes first check of mHTMLEditor in each method. If
this causes some security issues, we should add now. However, automated
tests don't indicate it.
Anyway, it should be fixed by bug 1454900 in same cycle.
MozReview-Commit-ID: 3LAtOQHyR5J
--HG--
extra : rebase_source : 48b78cb9477c6c47d23a864404ce95ca9edb8588
This patch adds a debug methods to check if AutoSafeEditorData as expected and
inserting top of each method whose mTextEditor is replaced with TextEditorRef().
MozReview-Commit-ID: 8yjHsypLMRx
--HG--
extra : rebase_source : 0c07d18d102d6ffe6f4bc0cf50ad0dfca1f8bd4d
Except HTMLEditRules::WillJoinNodes(), observer methods of HTMLEditRules
accesses mHTMLEditor. Therefore, we need to make them create AutoSafeEditorData
instance in the stack.
Note that for reducing EditorBase::GetSelection() calls, this patch adds
Selection& argument to all of them.
MozReview-Commit-ID: 6mjuD2gZwVp
--HG--
extra : rebase_source : 56f16747a80927f0477b9b54f6088be719ed7b01
This patch creates a stack class in TextEditRules, its name is
AutoSafeEditorData and make all public methods (except editor observer methods)
which may change DOM tree, fire some DOM events or calling some XPCOM listeners
create its instance in the stack. Then, it grabs associated editor instance
and its selection instance.
Next patch will make remaining public methods create AutoSafeEditorData.
MozReview-Commit-ID: 8oshdhL3ONQ
--HG--
extra : rebase_source : 591db71e45fe28ca93cbebd9bb7da8c16eae4466
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
Now that BeginUpdate is useless for the UPDATE_STYLE case, we don't need the
update mechanism at all. Just ensure that ApplicableStylesChanged is called on
the pres shell via the relevant RuleChanged, etc. notifications.
There's a big hidden gotcha here. nsIDocument::BeginUpdate does put a script
blocker on the stack for these updates. However it's not needed, since no script
can run during these notifications (only the stylesheet events we post for
devtools, but those use AsyncEventDispatcher and PostDOMEvents, so they don't
try to run immediately).
nsIDocument::BeginUpdate also does XBL binding attached queue stuff, but we
can't change bindings during these notifications anyway, so it also doesn't
matter.
MozReview-Commit-ID: HJvK6zQfloh
It's been removed for a while on Nightly without any known regressions. This
gives us a full beta cycle of telemetry and two nightly cycles without the API
before shipping.
This only removes the API, followup work will replace serialization by Servo's,
and remove the remaining DOM interfaces.
MozReview-Commit-ID: 2m1taYg5xEr
Masayuki Nakano
Dorel Luca
Makoto Kato
Kris Maglione
Boris Zbarsky
Emilio Cobos Álvarez
Adrian Wielgosik
Cosmin Sabou
Chris Peterson