Neither comm-central nor BlueGriffon uses nsIHTMLEditor.getFontColorSetate().
So, we can get rid of this from nsIHTMLEditor. However, we need to keep it
as a non-virtual public method since it's used by FontColorStateCommand.
Differential Revision: https://phabricator.services.mozilla.com/D4303
--HG--
extra : moz-landing-system : lando
HTMLEditor::CheckSelectionStateForAnonymousButtons() is called a lot internally.
Especially, its virtual call cost may make damage to our performance since
it's called from a selection listener.
So, we should create non-virtual method, RefereshEditingUI() for internal use.
RemoveList doesn't use aListType parameter, but c-c still call this method.
So I keep aListType parameter even if unused.
Differential Revision: https://phabricator.services.mozilla.com/D3762
--HG--
extra : moz-landing-system : lando
Nobody (including comm-central and BlueGriffon) does not use "namedanchor"
special element name with those XPCOMs. Of course, our internal callers too.
Therefore, we can drop.
Note that there is no static Atom for this, so, keeping it makes unnecessary
runtime cost for Firefox users.
This could cause breaking some legacy add-ons for Thunderbird. However,
they can use "anchor" special element name for same purpose.
Differential Revision: https://phabricator.services.mozilla.com/D3585
--HG--
extra : moz-landing-system : lando
HTMLElementOrParentByTagName() is the last user of IsLinkTag(const nsAString&)
and IsNamedAnchorTag(const nsAString&). For making their maintenance easier,
let's make GetElementOrParentByTagName() take const nsAtom& for tag name.
GetElementOrParentByTagName() has two functions, one is looking for an element
starting from a node. The other is, if the start node is nullptr, it retrieves
anchor node of Selection as start node. Therefore, this patch splits the
first part to GetElementOrParentByTagNameInternal(). Then, creates its
wrapper which retrieves anchor of Selection automatically,
GetElementOrParentByTagNameAtSelection().
Additionally, this patch makes all internal callers of HTMLEditor use
GetElementOrParentByTagNameInternal() or
GetElementOrParentByTagNameAtSelection() directly. Then, public method,
GetElementOrParentByTagName() is called only by outer classes.
Note that some callers use both GetElementOrParentByTagNameInternal()
and GetElementOrParentByTagNameAtSelection() since they don't check whether
setting node is nullptr. They may be bug of them. We should investigate
the API callers later.
Differential Revision: https://phabricator.services.mozilla.com/D3584
--HG--
extra : moz-landing-system : lando
Nobody (including comm-central and BlueGriffon) does not use "namedanchor"
special element name with those XPCOMs. Of course, our internal callers too.
Therefore, we can drop.
Note that there is no static Atom for this, so, keeping it makes unnecessary
runtime cost for Firefox users.
This could cause breaking some legacy add-ons for Thunderbird. However,
they can use "anchor" special element name for same purpose.
Differential Revision: https://phabricator.services.mozilla.com/D3585
--HG--
extra : moz-landing-system : lando
HTMLElementOrParentByTagName() is the last user of IsLinkTag(const nsAString&)
and IsNamedAnchorTag(const nsAString&). For making their maintenance easier,
let's make GetElementOrParentByTagName() take const nsAtom& for tag name.
GetElementOrParentByTagName() has two functions, one is looking for an element
starting from a node. The other is, if the start node is nullptr, it retrieves
anchor node of Selection as start node. Therefore, this patch splits the
first part to GetElementOrParentByTagNameInternal(). Then, creates its
wrapper which retrieves anchor of Selection automatically,
GetElementOrParentByTagNameAtSelection().
Additionally, this patch makes all internal callers of HTMLEditor use
GetElementOrParentByTagNameInternal() or
GetElementOrParentByTagNameAtSelection() directly. Then, public method,
GetElementOrParentByTagName() is called only by outer classes.
Note that some callers use both GetElementOrParentByTagNameInternal()
and GetElementOrParentByTagNameAtSelection() since they don't check whether
setting node is nullptr. They may be bug of them. We should investigate
the API callers later.
Differential Revision: https://phabricator.services.mozilla.com/D3584
--HG--
extra : moz-landing-system : lando
nsIHTMLEditor::ReplaceHeadContentsWithHTML() is used only by HTMLEditor
internally. So, it shouldn't be an nsIHTMLEditor's method. This patch
changes it as a non-virtual method of HTMLEditor and rename it to
ReplaceHeadContentsWithSourceWithTransaction() for consistency with other
methods.
MozReview-Commit-ID: GT3maKEbZuP
--HG--
extra : rebase_source : 2dc8c682f0dd82d3fc9032fbf5195de121975c32
insertHTMLWithContext, getIndentState, setBodyAttribute and
getSelectionContainer are unused from script (inc. c-c and bluegriffon).
Differential Revision: https://phabricator.services.mozilla.com/D1822
Since GetActiveEditingHost is noscript method, we should move this from
nsIHTMLEditor to HTMLEditor.
MozReview-Commit-ID: 3jLHSstixxk
--HG--
extra : rebase_source : 72e992a6c5643e1d0f0f5454f803139716c6309c
The only C++ caller immediately QIs the result anyway, and the exact type
returned doesn't matter for JS callers because the return values are DOM
objects. This makes it simpler to rejigger the internals to work with nsINode
and Element and whatnot.
MozReview-Commit-ID: 863IDGECqYY
c-c and bluegriffon don't use this method, so let's remove it to clean up.
MozReview-Commit-ID: BC5Ooy2Jlb9
--HG--
extra : rebase_source : 86e49ef864d5c78049673924c385e6cdbd0cb215
m-c, c-c and bluegriffon don't use this interface. So we should remove this.
MozReview-Commit-ID: 92VwGKlrOw5
--HG--
extra : rebase_source : 003763c6abc1406bcffabbffc3fe0696985ee97a
nsIHTMLEditor's addDefaultProperty(), removeDefaultProperty(),
removeAllDefaultProperties() methods are never used -- not from C++ code or
script, in either mozilla-central or comm-central.
So this patch removes them. This means that HMLTEditor::mDefaultStyles is never
used, so the patch removes it and all the code that manipulates it as well.
--HG--
extra : rebase_source : 76634ce2bb2d94534b8d7f299c4ebd6a83b66637
nsIHTMLEditor has several scriptable methods (addDefaultProperty(),
removeDefaultProperty(), etc.) that have nsIAtom parameters. We're in the
process of deCOMtaminating nsIAtom (bug 1392883) so these methods need to be
changed.
This patch does the following.
- It changes those methods to take an AString instead of an nsIAtom.
- For each existing method, it adds to HTMLEditor a new C++ method of the same
name that takes an nsIAtom parameter.
- It updates TextEditorTest.cpp to use strings instead of atoms, in order to
keep using the XPIDL methods.
- It updates test_bug1140105.html to pass strings instead of atoms to
getInlineProperty(). This removes the use of nsIAtomService.
--HG--
extra : rebase_source : e005c3b5a08207b3d5d5fb55c47c8bc475b33453
If we make nsIEditor a builtin class, that means that its instance can be only TextEditor or HTMLEditor. Then, users of nsIEditor can use concrete classes such as EditorBase, TextEditor or HTMLEditor instead. Then, the users can reduce unnecessary QI and a lot of virtual calls if we'll create non-virtual methods.
So, let's make editor related interfaces builtin classes.
MozReview-Commit-ID: 93WfsSDuJiJ
--HG--
extra : rebase_source : 39151eb4ffaaf195fec57234ea84c9f4066c58d1
Now, nobody (including add-ons) uses nsIHTMLEditor::SetDocumentTitle(), so, we can remove it.
Additionally, mozilla::SetDocumentTitleTransaction is created only when nsIHMLEditor::SetDocumentTitle(), so, we can remove this class too.
MozReview-Commit-ID: HK7G9u7HUlh
--HG--
extra : rebase_source : da68cabbf929a684d26f6316fdc7f58b8e32ab02
c-c nor add-ons seem noet to use it. We should remove this.
MozReview-Commit-ID: 3jN8kUp6D4Z
--HG--
extra : rebase_source : cc31001bb87da2888a9c1da6d92a305cdebebb7a
Masayuki Nakano
Dorel Luca
Makoto Kato
Noemi Erli
Boris Zbarsky
Adrian Wielgosik
Nicholas Nethercote
aceman
Ehsan Akhgari
Olli Pettay
Birunthan Mohanathas