Граф коммитов

54 Коммитов

Автор SHA1 Сообщение Дата
Masayuki Nakano 8b7e7ba3d1 Bug 1540029 - part 8: Replace `HTMLEditRules::GetParagraphState()` with new stack only class r=m_kato
Differential Revision: https://phabricator.services.mozilla.com/D45790

--HG--
extra : moz-landing-system : lando
2019-09-18 08:20:29 +00:00
Masayuki Nakano ed4c1cd65a Bug 1540029 - part 7: Replace `HTMLEditRules::GetAlignment()` with new stack only class r=m_kato
Differential Revision: https://phabricator.services.mozilla.com/D45789

--HG--
extra : moz-landing-system : lando
2019-09-18 06:26:56 +00:00
Masayuki Nakano 6ff81fdbe4 Bug 1540029 - part 6: Replace `HTMLEditRules::GetListItemState()` with new stack only class r=m_kato
Differential Revision: https://phabricator.services.mozilla.com/D45788

--HG--
extra : moz-landing-system : lando
2019-09-18 04:42:55 +00:00
Masayuki Nakano 320d1209c9 Bug 1540029 - part 5: Replace `HTMLEditRules::GetListState()` with new stack class r=m_kato
It takes a lot of `bool` out arguments.  Therefore, we should make it a
stack only class and caller should retrieve only necessary information.

Differential Revision: https://phabricator.services.mozilla.com/D45787

--HG--
extra : moz-landing-system : lando
2019-09-18 03:39:00 +00:00
Masayuki Nakano b1ead5a6f3 Bug 1574852 - part 86: Move `HTMLEditRules::WillAlign()` and `HTMLEditRules::AlignContentsAtSelection()` to `HTMLEditor` r=m_kato
And also this splits large 2 blocks of
`HTMLEditRules::AlignContentsAtSelection()` to 2 methods.

Differential Revision: https://phabricator.services.mozilla.com/D44790

--HG--
extra : moz-landing-system : lando
2019-09-09 04:57:50 +00:00
Masayuki Nakano de7cc1a3a0 Bug 1574852 - part 71: Move `HTMLEditRules::WillRemoveList()` to `HTMLEditor` r=m_kato
Differential Revision: https://phabricator.services.mozilla.com/D44464

--HG--
extra : moz-landing-system : lando
2019-09-06 06:01:57 +00:00
Makoto Kato 9d24379b0f Bug 1577969 - Get rid of nsIHTMLEditor.getLinkedObject and nsIURIRefObject. r=masayuki
Since bug 1577443 is landed in comm-central, no one uses `nsIHTMLEditor.getLinkedObject`.

Differential Revision: https://phabricator.services.mozilla.com/D44361

--HG--
extra : moz-landing-system : lando
2019-09-02 12:15:41 +00:00
Masayuki Nakano 19fbb1a392 Bug 1549925 - Mark all methods of nsIDocumentStateListener as can_run_script r=m_kato
`nsIDocumentStateListener` is a scriptable interface and each method may run
any script.  So, we should mark them as `can_run_script`.  Then, we need to
mark a lot of editing methods because we need to mark
`EditorBase::EndTransactionInternal()` and `EditorBase::DoTransactionInternal()`
as `MOZ_CAN_RUN_SCRIPT`.

Differential Revision: https://phabricator.services.mozilla.com/D30360

--HG--
extra : moz-landing-system : lando
2019-05-09 07:37:51 +00:00
Masayuki Nakano 6d224d7259 Bug 1549270 - part 2: Mark EditorBase::RemoveAttributeWithTransaction() as MOZ_CAN_RUN_SCRIPT r=m_kato
Differential Revision: https://phabricator.services.mozilla.com/D30044

--HG--
extra : moz-landing-system : lando
2019-05-08 05:09:56 +00:00
Masayuki Nakano f440ac739a Bug 1549264 - Mark EditorBase::SplitNodeWithTransaction() as MOZ_CAN_RUN_SCRIPT r=m_kato
Differential Revision: https://phabricator.services.mozilla.com/D30039

--HG--
extra : moz-landing-system : lando
2019-05-07 22:34:28 +00:00
Masayuki Nakano 3e64f2c30d Bug 1539356 - Mark EditorBase::InsertNodeTransaction() as MOZ_CAN_RUN_SCRIPT r=m_kato
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.

Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree.  Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.

Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.

Differential Revision: https://phabricator.services.mozilla.com/D25027

--HG--
extra : moz-landing-system : lando
2019-03-30 11:55:29 +00:00
Oana Pop Rus 43fadb6745 Backed out changeset 447c87c2d139 (bug 1539356) on request of Jorg K. a=backout 2019-03-30 00:42:32 +02:00
Masayuki Nakano 81b30d7143 Bug 1539356 - Mark EditorBase::InsertNodeTransaction() as MOZ_CAN_RUN_SCRIPT r=m_kato
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.

Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree.  Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.

Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.

Differential Revision: https://phabricator.services.mozilla.com/D25027

--HG--
extra : moz-landing-system : lando
2019-03-29 10:55:31 +00:00
Masayuki Nakano 0a753c3aac Bug 1533293 - part 3: Make editor and ContentEventHandler not use Selection::Extend() due to too slow r=m_kato
`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places.  We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`.  The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.

Differential Revision: https://phabricator.services.mozilla.com/D23462

--HG--
extra : moz-landing-system : lando
2019-03-26 10:09:47 +00:00
Masayuki Nakano 534fd23ca4 Bug 1533293 - part 2: Rewrite EditorBase::SelectEntireDocument() and its overrides r=m_kato
`EditorBase::SelectEntierDocument()` uses `Selection::Extend()` but it's too
slow.  It should use `Selection::SetStartAndEndInLimiter()` instead.

Additionally, `TextEditor::SelectEntierDocument()` shrink the result of
`EditorBase::SelectEntierDocument()` with `Selection::Extend()` if there is
a `moz-<br>` element.  So, `TextEditor::SelectEntinerDocument()` should set
its expected selection with a call for saving the runtime cost.

Then, we don't need to make `EditorBase::SelectEntierDocument()` as non-pure
virtual method.  So, this patch makes each its callers call
`Selection->SelectAllChildren()` directly.

Differential Revision: https://phabricator.services.mozilla.com/D23461

--HG--
extra : moz-landing-system : lando
2019-03-26 10:06:43 +00:00
Noemi Erli 165f0d8c1c Backed out 3 changesets (bug 1533293) for causing Bug 1536595 a=backout
Backed out changeset d011dfe83683 (bug 1533293)
Backed out changeset e536f6e123d8 (bug 1533293)
Backed out changeset 19cff61f4fed (bug 1533293)
2019-03-20 13:29:17 +02:00
Masayuki Nakano 6dd0ecdd8e Bug 1533293 - part 3: Make editor and ContentEventHandler not use Selection::Extend() due to too slow r=m_kato
`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places.  We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`.  The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.

Differential Revision: https://phabricator.services.mozilla.com/D23462

--HG--
extra : moz-landing-system : lando
2019-03-18 01:52:36 +00:00
Masayuki Nakano 448571fd81 Bug 1533293 - part 2: Rewrite EditorBase::SelectEntireDocument() and its overrides r=m_kato
`EditorBase::SelectEntierDocument()` uses `Selection::Extend()` but it's too
slow.  It should use `Selection::SetStartAndEndInLimiter()` instead.

Additionally, `TextEditor::SelectEntierDocument()` shrink the result of
`EditorBase::SelectEntierDocument()` with `Selection::Extend()` if there is
a `moz-<br>` element.  So, `TextEditor::SelectEntinerDocument()` should set
its expected selection with a call for saving the runtime cost.

Then, we don't need to make `EditorBase::SelectEntierDocument()` as non-pure
virtual method.  So, this patch makes each its callers call
`Selection->SelectAllChildren()` directly.

Differential Revision: https://phabricator.services.mozilla.com/D23461

--HG--
extra : moz-landing-system : lando
2019-03-18 01:51:53 +00:00
Boris Zbarsky 9a4ba73134 Bug 1534370 part 3. Mark InsertFromTransferable as MOZ_CAN_RUN_SCRIPT. r=masayuki
Differential Revision: https://phabricator.services.mozilla.com/D23042

--HG--
extra : moz-landing-system : lando
2019-03-12 01:55:03 +00:00
Masayuki Nakano 7348477018 Bug 1510183 - Make HTMLEditor treat empty string attribute of style as nullptr of nsAtom rather than nsGkAtoms::_empty r=m_kato
After fixing bug 1427060, HTMLEditor treats attribute of style as nullptr.
However, if empty string is used to call NS_Atomize(), it returns
nsGkAtoms::_empty.  Therefore, HTMLEditor fails to check whether attribute is
specified or not with nullptr check since some root callers sets
nsGkAtoms::_empty instead of nullptr.

This patch makes HTMLEditor always use nullptr for empty string of attribute
of style with wrapping NS_Atomize() with AtomzieAttribute().  Additionally,
for safer change, this patch makes PropItem and TypeInState treat
nsGkAtom::_empty as nullptr.

Differential Revision: https://phabricator.services.mozilla.com/D13203

--HG--
extra : moz-landing-system : lando
2018-11-30 01:21:59 +00:00
Masayuki Nakano 2bde324acf Bug 1501663 - part 7: HTMLEditor::GetSelectedElement() shouldn't return element node when Selection starts before the element node r=m_kato
This fixes odd case of this API.  GetSelectedElement() ignores non-element
nodes before an element node.  This must be intended to allow Selection to
start from in an element node.  However, current code allows to select starting
from previous text node.  This patch changes this behavior to stop looking
for element node if non-element node appears before an element node.

Differential Revision: https://phabricator.services.mozilla.com/D10703

--HG--
extra : moz-landing-system : lando
2018-11-05 11:38:10 +00:00
Masayuki Nakano f91716e775 Bug 1465702 - part 5: Remove unnecessary Selection argument from editor module r=m_kato
EditorBase::SelectionRefPtr() is now safe to use in editor and really fast to
retrieve Selection than EditorBase::GetSelection().  Therefore, we can get rid of
all Selection pointer/reference argument of each method which always take
normal Selection.

Note that this changes nsIHTMLEditor.checkSelectionStateForAnonymousButtons()
because its argument is only Selection.  So, BlueGriffon should work even
though it calls the method with nsIEditor.selection.

Differential Revision: https://phabricator.services.mozilla.com/D10009

--HG--
extra : moz-landing-system : lando
2018-10-30 10:01:38 +00:00
Masayuki Nakano f4b10b4e0f Bug 1485934 - Get rid of nsIHTMLEditor.getFontColorState() r=m_kato
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
2018-08-27 06:52:35 +00:00
Dorel Luca d11c177f44 Merge mozilla-central to mozilla-inbound 2018-08-21 12:59:51 +03:00
Masayuki Nakano 7fc2bdaae1 Bug 1484110 - part 1: Create HTMLEditor::RefereshEditingUI() for internal use of nsIHTMLEditor::CheckSelectionStateForAnonymousButtons() r=m_kato
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.
2018-08-17 17:56:28 +09:00
Makoto Kato a86db13435 Bug 1484612 - Remove EditSubActionInfo.bOrdered due to unused. r=masayuki
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
2018-08-20 12:23:56 +00:00
Masayuki Nakano 65bb9451c3 Bug 1484092 - part 2: Drop supporting "namedanchor" special element name from nsIHTMLEditor::GetSelectedElement(), nsIHTMLEditor::GetElementOrParentByTagName() and nsIHTMLEditor::CreateElementWithDefaults() r=m_kato
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
2018-08-17 14:50:56 +00:00
Masayuki Nakano b212948c3b Bug 1484092 - part 1: Make HTMLEditor::GetElementOrParentByTagName() use nsAtom for the tag name r=m_kato
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
2018-08-17 14:06:18 +00:00
Noemi Erli 79400be144 Backed out 2 changesets (bug 1484092) for build bustages in builds/worker/workspace/build/src/editor/libeditor/HTMLEditor.cpp💯53 on a CLOSED TREE
Backed out changeset 10fdd041f1b5 (bug 1484092)
Backed out changeset d0b14e8711df (bug 1484092)
2018-08-17 13:39:44 +03:00
Masayuki Nakano 16a97643c7 Bug 1484092 - part 2: Drop supporting "namedanchor" special element name from nsIHTMLEditor::GetSelectedElement(), nsIHTMLEditor::GetElementOrParentByTagName() and nsIHTMLEditor::CreateElementWithDefaults() r=m_kato
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
2018-08-17 07:41:55 +00:00
Masayuki Nakano a8b7670d10 Bug 1484092 - part 1: Make HTMLEditor::GetElementOrParentByTagName() use nsAtom for the tag name r=m_kato
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
2018-08-17 10:04:42 +00:00
Masayuki Nakano 905e9bda47 Bug 1476906 - Change nsIHTMLEditor::ReplaceHeadContentsWithHTML() to a non-virtual method of HTMLEditor r=m_kato
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
2018-07-19 21:31:19 +09:00
Makoto Kato 8bd7e4fabf Bug 1471115 - Remove unused methods in nsIHTMLEditor. r=masayuki
insertHTMLWithContext, getIndentState, setBodyAttribute and
getSelectionContainer are unused from script (inc. c-c and bluegriffon).

Differential Revision: https://phabricator.services.mozilla.com/D1822
2018-06-26 04:29:36 +00:00
Makoto Kato 35f52b478b Bug 1466469 - Devirtialize nsIHTMLEditor.GetActiveEditingHost. r=masayuki
Since GetActiveEditingHost is noscript method, we should move this from
nsIHTMLEditor to HTMLEditor.

MozReview-Commit-ID: 3jLHSstixxk

--HG--
extra : rebase_source : 72e992a6c5643e1d0f0f5454f803139716c6309c
2018-06-04 17:45:34 +09:00
Boris Zbarsky 0f8f7f6fba Bug 1463981 part 2. Remove use of nsIDOMNode in editor xpidl. r=masayuki 2018-05-24 13:18:34 -04:00
Adrian Wielgosik 3a8ef6cf8a Bug 1460940 - Remove nsIDOMDocument uses in editor/. r=bz
MozReview-Commit-ID: 8doC9drkrG9

--HG--
extra : rebase_source : 24ac8ea960faff10b04ef0f419bc6dc7b6556452
2018-05-11 19:46:15 +02:00
Boris Zbarsky 921ee1d522 Bug 1387143 part 4. Stop using nsISelection in remaining xpidl. r=mats 2018-05-08 13:52:36 -04:00
Boris Zbarsky 550b06a56b Bug 1455674 part 4. Stop using nsIDOMElement in nsIHTMLEditor::GetElementOrParentByTagName. r=masayuki 2018-04-26 23:35:18 -04:00
Boris Zbarsky aab9f97f4e Bug 1455674 part 2. Mostly stop using nsIDOMElement in nsIHTMLEditor. r=masayuki
MozReview-Commit-ID: Koxv2qS2gft
2018-04-26 23:35:18 -04:00
Boris Zbarsky 1fa8ecc716 Bug 1432944 part 2. Make nsIHTMLEditor.getSelectedElement return nsISupports. r=m_kato
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
2018-01-29 23:27:59 -05:00
Boris Zbarsky 7bb421fe3b Bug 1432944 part 1. Stop returning NS_EDITOR_ELEMENT_NOT_FOUND from nsIHTMLEditor::GetSelectedElement. r=m_kato
The only C++ caller doesn't care, and JS callers can't tell that a non-NS_OK success code was returned anyway.

MozReview-Commit-ID: FNhQYR0a9ur
2018-01-29 23:27:58 -05:00
Makoto Kato e8bfc9ec8b Bug 1428237 - Remove unused nsIHTMLEditor.getHeadContentsAsHTML. r=masayuki
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
2018-01-05 10:59:37 +09:00
Makoto Kato 9761443d2a Bug 1417400 - Get rid of nsIContentFilter. r=masayuki
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
2017-11-16 13:36:10 +09:00
Nicholas Nethercote 0eadf50d37 Bug 1394583 - Remove default properties from nsIHTMLEditor. r=masayuki.
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
2017-08-25 16:59:17 +10:00
Nicholas Nethercote c7df832636 Bug 1393642 - Remove nsIAtom/nsIAtomService usage from script in editor/. r=masayuki.
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
2017-08-25 15:40:45 +10:00
Masayuki Nakano a2333fc4bb Bug 1060051 - Make editor related interfaces builtin classes if it's possible r=Ehsan,smaug
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
2017-08-04 13:57:56 +09:00
Masayuki Nakano c20fedebf4 Bug 1312991 Get rid of nsIHTMLEditor::SetDocumentTitle() and mozilla::SetDocumentTitleTransaction r=smaug
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
2016-12-26 17:46:23 +09:00
Makoto Kato ced4cccc2c Bug 1313986 - Part 5. Remove createAnonymousElement from nsIHTMLEditor. r=masayuki
c-c nor add-ons seem noet to use it.  We should remove this.

MozReview-Commit-ID: 3jN8kUp6D4Z

--HG--
extra : rebase_source : cc31001bb87da2888a9c1da6d92a305cdebebb7a
2016-10-31 18:06:27 +09:00
aceman 8667dcbcb6 Bug 1273001 - convert HTMLEditor::getLinkedObjects() to nsIArray. r=masayuki 2016-09-20 12:47:00 +02:00
Masayuki Nakano 274f4c6cb1 Bug 1169139 Remove all trailing whitespaces in editor (IGNORE IDL) r=ehsan 2015-05-29 00:58:42 +09:00