This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
mozInlineSpellChecker listens to only DidSplitNode() and DidJoinNodes().
So, EditorBase should call them directly rather than treating it as an
nsIEditActionListener since its runtime cost becomes really cheaper.
Different from EditorSpellCheck, nobody creates instance of
nsIInlineSpellChecker. So, we can now stop supporting createInstance() for it
in chrome JS and should do this since EditorBase cannot support multiple
mozInlineSpellChecker instances without nsIEditActionListener interface.
Therefore, this patch removes the entry from factory.
MozReview-Commit-ID: W1CLdsJaaB
--HG--
extra : rebase_source : 2319999e4b1fc8978386c49236d5d24d78d86047
mozSpellChecker stores TextServicesDocument, EditorSpellCheck stores
mozSpellChecker and mozInlineSpellChecker stores EditorSpellCheck.
So, they should have accessors for their member. Then, EditorBase can
access all of them.
MozReview-Commit-ID: Igphm8nRqve
--HG--
extra : rebase_source : 0c70bf3e23f16ea6a97b49901f4b1c87e7da6d37
EditorBase::mInlineSpellChecker is always an instance of mozInlineSpellChecker.
Fortunately, it's easy to expose mozInlineSpellChecker.h. So, making EditorBase
store it as mozInlineSpellChecker directly, EditorBase can access any of
mozInlineSpellChecker, EditorSpellCheck, mozSpellChecker and
TextServicesDocument with new accessors created by following patch.
MozReview-Commit-ID: 2oyS5tPeQcg
--HG--
extra : rebase_source : a9ce2e4dbceff7ca800d34d60d56eba184298677
mozInlienSpellChecker::mSpellCheck and mozInlineSpellChecker::mPendingSpellCheck
are always instances of EditorSpellCheck because mozInlienSpellChecker creates
its instance. Therefore, making mozInlineSpellChecker store EditorSpellCheck
directly makes sense.
MozReview-Commit-ID: LTtEMZqMS9E
--HG--
extra : rebase_source : 94e4c4ada332e626d49de5782fca192fb7489064
nsEditorSpellCheck::mSpellChecker is always mozSpellChecker because it's
created only by nsEditorSpellCheck. Additionally, mozSpellChecker.h is
already exposed. So, nsEditorSpellCheck can store it as mozSpellChecker
directly.
MozReview-Commit-ID: 2vyDe4plncM
--HG--
extra : rebase_source : 847b2f384163450ab44b94bc12ee489633a849b6
nsITextServicesDocument isn't used by anybody now. So, we can get rid of it.
Additionally, nsITextService and nsTextServicesFactory are not also used by
anybody. Therefore, this patch removes all of them.
MozReview-Commit-ID: KSbMdm7QPKF
--HG--
extra : rebase_source : 724a5f48ad49b4231bacf7fba32c6a35d90121d0
Now, TextServicesDocument can be treated by anybody. So, let's make
mozSpellChecker and nsEditorSpellChecker treat it directly instead of
nsITextServicesDocument.
MozReview-Commit-ID: 2tMy6y3i17b
--HG--
extra : rebase_source : 2e6c79355a5e0a7044fbea989ba414a7bf1a7d8d
For making nsTextServicesDocument accessible from anywhere directly, we need to
expose its header. Then, it should be in mozilla namespace.
This patch renames nsTextServicesDocument to mozilla::TextServicesDocument
and expose the header file as "mozilla/TextServicesDocument.h".
MozReview-Commit-ID: 9PmP73PXSJu
--HG--
rename : editor/txtsvc/nsTextServicesDocument.cpp => editor/txtsvc/TextServicesDocument.cpp
rename : editor/txtsvc/nsTextServicesDocument.h => editor/txtsvc/TextServicesDocument.h
extra : rebase_source : a12081434d0bc002e3675178486cc7f8eaaa3256
Most nsIEditActionListener::Will*() are not implemented, except
WillDeleteText() and WillDeleteSelection() which are implemented by
FinderHighlighter. So, we can get rid of the other Will*() from it.
This patch removes a lot of unnecessary virtual calls and copy of strong
pointers to edit action listeners of EditorBase.
MozReview-Commit-ID: EsqI2tZoBG1
--HG--
extra : rebase_source : cf78eb8d33b12ca65177b0676f6e45d02e7c0688
For calling some methods of mRules from EditorBase, let's move mRules member
from TextEditor to EditorBase.
Unfortunately, TextEditRules.h depends on EditAction which is declared in
EditorBase.h and that caused unnecessary include hell of EditorBase.h. So,
let's move it to an independent header file.
MozReview-Commit-ID: 5HiSZLP9WHH
--HG--
extra : rebase_source : 3e2c40385a6f3d6d1e03ef4e213434383bb37d5f
nsIEditorSpellCheck still uses wstring. We should replace it with AString
to avoid additional memory allocation.
MozReview-Commit-ID: H4jKY2tylqg
--HG--
extra : rebase_source : c1f0325eb2efbfb07f53514b96121a5ceb58efd4
Although nsIEditActionListener::WillInsertNode() nobody implements actually,
we should remove it in a follow up bug.
nsIEditActionListener::DidInsertNode() is implemented only by HTMLEditRules.
So, if we make it not use nsIEditActionListener, we can remove it too.
However, keep it for now.
On the other hand, they don't need to receive index of the insertion point.
WillInsertNode() needs next sibling of the insert point, but DidInsertNode()
needs nothing because listener can compute it with new inserted node.
MozReview-Commit-ID: GiTKkVyZJlN
--HG--
extra : rebase_source : 9ee38c28217d25d1a3f79b0b458c7b2121350a76
Remove the headers included for "backwards compatibility" and just include them
where required.
--HG--
extra : source : e2beba7e6875120ebbbcadf24bcbcb5b86411a94
extra : amend_source : 11f07a27431cd468511f0bd45afe36150c6e342c
Remove the headers included for "backwards compatibility" and just include them
where required.
--HG--
extra : rebase_source : 03e703a81ed4b80f4f116ff36d8787464ce5acba
No one uses nsIInlineSpellChecker.spellCheckAfterEditorChange from script.
So I think we can mark this interface as noscript.
Since this method is scriptable, we need QI to get nsIDOMNode. If we can
change to noscript, it can reduce QI to get nsIDOMNode.
MozReview-Commit-ID: GC0WuFyTlaZ
--HG--
extra : rebase_source : 16ca9fc548e86747ac17407be48295c709174fb5
nsIEditActionListner::DidSplitNode() takes 4 arguments, the right node,
old offset in the old right node before splitting, the new left node and
nsresult.
Computing offset for this doesn't make sense because it's always same as
the length of the left node. Additionally, nobody currently use nsersult.
So, we can get rid of it now.
Fortunately, nobody including comm-central and BlueGriffon implements
WillSplitNode(). So, we can get rid of it. However, removing interface
method should be done in a follow up bug. So, we can remove offset computation
in EditorBase::SplitNode() completely in the future.
MozReview-Commit-ID: JWj34SjBNJh
--HG--
extra : rebase_source : f0e1ed0e466dc8217c1a0ab1722790883a7efd1f
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
Cosmin Sabou
Boris Zbarsky
Kris Maglione
Brindusan Cristian
Masayuki Nakano
Ekanan Ketunuti
Cameron McCormack
jj.evelyn@gmail.com
Andrea Marchesini
Emilio Cobos Álvarez
Florian Quèze
Makoto Kato
Eric Rahm
Csoregi Natalia
Gurzau Raul
Sylvestre Ledru
Masatoshi Kimura
Ryan VanderMeulen
Coroiu Cristina
Ted Mielczarek
Margareta Eliza Balazs