inlineTableEditingEnabled and refreshInlineTableEditingUI are used by
bluegriffon, but other methods aren't used by m-c, c-c and bluegriffon.
So I would like to remove these methods. Then we can clean up
DoInlineTableEditingAction.
MozReview-Commit-ID: 3R0bJDU5vqv
--HG--
extra : rebase_source : 74c7615613bba65326069929cb53c3ea48f2e9a4
extra : amend_source : a1ac9af3de50daa0cbfd98e2790afa402d9932ef
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
comm-central and bluegriffon don't use mosueDown, mouseUp and mouseMove in
nsIHTMLObjectResizer, so we should remove these methods from this interface.
MozReview-Commit-ID: BnSkkH7f0xc
--HG--
extra : rebase_source : 40811e1a0b714e3ef30fd9ac5e4f840241de3780
Actually, PopItem uses nsString to store attribute name. And when using it,
it converts to nsAtom by NS_Atomize and compare by nsString.
To reduce calculation of atom and string compare, we should store atom directly.
MozReview-Commit-ID: 8OB02mgMg1r
--HG--
extra : rebase_source : 9861217804acac52106a89cad75e08bd547080ad
extra : histedit_source : 2b9f01cf29b1b09dd07fc771ff94a06be4d94f31
nsIEditRules is a super class of only mozilla::TextEditRules and not scriptable.
So, we can get rid of it.
This patch merges RulesInfo with TextRulesInfo and name new class is RulesInfo
for minimizing the code change.
Additionally, adds two methods AsHTMLEditRules() and its const version.
They make existing cast code safer.
MozReview-Commit-ID: KwWH3ADj3Bv
--HG--
extra : rebase_source : 4517bdc95b530530e9756e07c4b6cce78c002073
Despite of its name, HTMLEditor::IsVisTextNode() returns true with its out
argument when the given text node is empty. And although it returns nsresult,
it's almost always NS_OK because it returns error only when the editor isn't
usual condition.
So, it should return bool and true when the given text node is visible.
This patch separates the method. One is for checking the node with frames,
called IsInVisibleTextFrames(). The other is for checking it only with
its text, called IsVisibleTextNode().
MozReview-Commit-ID: EdQmkOxfNxO
--HG--
extra : rebase_source : ad9d42f6c8a8e17145f0ca92cd5c02994f8a6b37
The only caller is HTMLEditor::IsEmptyNodeImpl(). So, we can get rid of it.
MozReview-Commit-ID: GTJiXwSCrwM
--HG--
extra : rebase_source : a44b277547d0641f244ff363f5cde8ae44b13eda
mInlineEditedCell for inline table editor is still nsIDOMElement. To avoid QI
and virtual call, we should replace it with Element.
MozReview-Commit-ID: 76yfQJxwm9d
--HG--
extra : rebase_source : e89de17faa20d16a8823e1016b6ba8a6f78993b6
EditorDOMPointBase::Container() may return nullptr. So, it should be renamed
to GetContainer().
Then, the method name becomes longer and a lot of callers access the result
directly. So, there should be following methods to make the callers shorter:
- GetContainerAsContent() to return the container as nsIContent*.
- GetContainerAsElement() to return the container as dom::Element*.
- GetContainerAsText() to return the container as dom::Text.
- GetContainerAsDOMNode() to return the container as nsIDOMNode*.
- CanContainerHaveChildren() to check if the container can have child nodes.
- IsInDataNode() to check if the point is in a data node including text node.
- IsInTextNode() to check if the point is in a text node.
- IsContainerHTMLElement() to check if the container is specific HTML element.
- IsContainerAnyOfHTMLElements() to check if the container is one of the
specified HTML elements.
MozReview-Commit-ID: LkN2WBbCPj0
--HG--
extra : rebase_source : 9da1e70d4c74f7ad573e244cf6c7b21a0c7b4410
HTMLEditor::NormalizeEOLInsertPosition() takes a set of container node and
offset in it for specifying insertion point. So, this should be replaced
with |const EditorRawDOMPoint&| and it should return |EditorDOMPoint| rather
than modifying the argument.
Additionally, perhaps, GetBetterInsertionPointFor() is better name for it.
MozReview-Commit-ID: IB1FhrkzK2G
--HG--
extra : rebase_source : 55f8c1d9fa1f149e81114c929f6e6232aba03905
HTMLEditor::InsertNodeAtPoint() should take |const EditorRawDOMPoint&| as
an argument which specifies point to insert. Additionally, it should take
|EditorDOMPoint*| to return the next point of actual insertion point.
Additionally, this patch renames it to InsertNodeAtProperAncestor() for
explaining what it will do.
MozReview-Commit-ID: HYUzSlyPxAd
--HG--
extra : rebase_source : 57033cdc4458b45a5fe9d6aa642c185133a79304
TextEditor::CreateBRImpl() should take |const EditorRawDOMPoint&| as insertion
point of new <br> element. Additionally, it doesn't need to have out argument
for the point of after <br> element because callers can get it with
EditorRawDOMPoint(nsINode*) and the new <br> node, and calling AdvanceOffset().
This cost must be enough cheap.
MozReview-Commit-ID: Hxawz3D2dCd
--HG--
extra : rebase_source : 866ff50efd70499ed733da9efcce7399f44bd4a0
One of CreateBR is still virtual method, but it is unnecessary to use it.
So we should remove virtual keyword and remove override method.
Also, we should move native dom version of CreateBR to TextEditor to use it
on TextEdtitor.
MozReview-Commit-ID: GCazJtY4urV
--HG--
extra : rebase_source : 8e0d71631f0070a928bc0f4817dd6efe7c833f1b
EmptyContainers::yes and EmptyContainers::no are not so clear name what they
mean.
They means whether NodeSplitDeep() creates or won't create empty nodes when
split point is at start edge or end edge of an element.
This patch renames them to SplitAtEdges::eDoNotCreateEmptyContainer and
SplitAtEdges::eAllowToCreateEmptyContainer and make
HTMLEditor::InsertNodeAtPoint() use it instead of an bool argument.
Additionally, the argument of NodeSplitDeep() is now not optional because
this difference is really important when you read around the callers.
MozReview-Commit-ID: 9hpMRkVDvCg
--HG--
extra : rebase_source : ee892361d66c9c9c5ed45ee9d3321474257ac417
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
No one uses out parameter of InsertBR, so we should remove it. Also, CreateBR
has direction parameter for selection, so we should use it.
MozReview-Commit-ID: 8heqaXpR9He
--HG--
extra : rebase_source : 27b952f080a70fe039c9b43d7ae9f1394d4de01e
HTMLEditor::GetNextHTMLNode() should be redesigned as
HTMLEditor::GetNextEditableHTMLNode(nsINode&),
HTMLEditor::GetNextEditableHTMLNodeInBlock(nsINode&),
HTMLEditor::GetNextEditableHTMLNode(const EditorRawDOMPoint&) and
HTMLEditor::GetNextEditableHTMLNodeInBlock(const EditorRawDOMPoint&).
Same as GetPreviousEditableHTMLNode*(), we don't need the methods to find
non-editable nodes too.
MozReview-Commit-ID: JjZauCMblp4
--HG--
extra : rebase_source : 1e650d79bc21d7f920b3f46f4a2f208ac23cc0a6
HTMLEditor::GetPriorHTMLNode() methods are similar to EditorBase::GetPriorNode()
which was redesigned with the previous patch.
So, it should be redesigned as
HTMLEditor::GetPreviousEditableHTMLNode(nsINode&),
HTMLEditor::GetPreviousEditableHTMLNode(const EditorRawDOMPoint&),
HTMLEditor::GetPreviousEditableHTMLNodeInBlock(nsINode&) and
HTMLEditor::GetPreviousEditableHTMLNodeInBlock(const EditorRawDOMPoint&).
Note that HTMLEditor::GetPriorHTMLNode() are always return editable node.
So, we don't need to create non-editable node methods for them.
Although, I don't like the word "HTMLNode" because this can return SVG element
or something too. The additional feature of those methods is just checking
given node is in active editing host. So, they are for HTML editor, but not
returning only HTML nodes. However, I have no better idea with shorter name.
MozReview-Commit-ID: 3J4IaBOFjzj
--HG--
extra : rebase_source : 712bc8676fcdc37f38fd46083df177c0fe6bd408
EditorBase::InsertTextImpl() takes |nsCOMPtr<nsINode>*|, |nsCOMPtr<nsIContent>*|
and |int32_t| as in/out arguments for container, child and offset of the child
in the container. But this makes the callers really hard to read and ugly.
So, we should make the method take |const EditorRawDOMPoint&| argument as input
and |EditorRawDOMPoint*| as out argument.
MozReview-Commit-ID: 2ijIfGl4Zo7
--HG--
extra : rebase_source : b309d9bdc04aac620f138769ba18ad7e4597fe6c
Currently, HTMLEditRules::WillInsertBreak() checks if the editing host can
contain a <p> element as a child or a descendant. However, this is not enough.
If an inline element has a block element which can contain a <p> element,
current implementation considers to insert a <br>. This is possible when
* The editing host is an unknown element including user defined element.
* The editing host is an inline element and its children and/or descendants
were added by JS. E.g., <span contenteditable> element can have <div>
element.
I think that we should consider to insert a <br> element when:
- There is no block ancestors in the editing host.
- The editing host is the only block element and it cannot contain <p> element
or the default paragraph separator is <br> element.
- The nearest block ancestor isn't a single-line container declared in the
execCommand spec and there are no block elements which can contain <p>
element.
Note that Chromium checks if CSS box of ancestors is block too. However,
it must be out of scope of this bug.
MozReview-Commit-ID: HdjU9t83Nd1
--HG--
extra : rebase_source : 7030671268a610613359b5d8ae5d126e120f59bd
Perhaps, most callers don't need parent block outside active editing host.
Therefore, callers of these methods should be able to specify the editing
host for making those methods stop looking for a block ancestor.
Then, callers can avoid using EditorUtils::IsDescendantOf() and
nsContentUtils::IsContentDescendantOf().
MozReview-Commit-ID: 7IK4gAVHY5d
--HG--
extra : rebase_source : 31cd55026f0ce005d906499de4ebe5d1c39555e9
Currently, HTMLEditor::GetBlockNodeParent(nsIDOMNode*) is used only by
HTMLEditor::DoInsertHTMLWithContext() and there is a variable of nsINode*.
So, we don't need to keep it anymore.
MozReview-Commit-ID: LEWaiR5BEB9
--HG--
extra : rebase_source : 64ef772f3b7883bd4aae48dec737663e6036553b
Editor sometimes extracts atom to string to compare element name.
It is unnecessary to use atom directly.
MozReview-Commit-ID: FEvyiIeaozs
--HG--
extra : rebase_source : 4418d0c82fa4fedd814b914f2cf3a86d74ad9835
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
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
nsITableEditor is now a builtin class. So, it's implemented only by HTMLEditor. Therefore, AutoSelectionSetterAfterTableEdit can use HTMLEditor.
Then, nsITableEditor.setSelectionAfterTableEdit() can be removed from nsITableEditor and moved to HTMLEditor as non-virtual method since nobody uses it from JS.
MozReview-Commit-ID: KnN6Fw4TYyn
--HG--
extra : rebase_source : 48412a5f81f30d9ada47550fdb4d1ee0d88de6f4
nsComposerCommands uses some simple getter methods. They can be simpler non-virtual methods. So, we should do it.
Note that this changes that EditorBase::GetIsSelectionEditable() won't return error. However, it has returned error only when selection controller isn't available. That means that the selection controller has been destroyed and the editor will be destroyed. So, this must not be problem since it returns false (non-editable) instead and won't break any behavior since the editor won't be editable by users nor JS anymore.
MozReview-Commit-ID: E9ccFspG6na
--HG--
extra : rebase_source : bcd1314cb386fcaf175adabfefde5885decd87c0
nsIEditor is still first contact with editor class for some modules. They should be accessible to the concrete classes without QI. Therefore, nsIEditor should have As*Editor() methods.
Additionally, this adds AsEditorBase(). That is always implemented but it might be necessary for some files for minimizing its include files.
MozReview-Commit-ID: 8WqkDJLiVDs
--HG--
extra : rebase_source : e51282df244efad62bc6fe04ab449e3beab440f9
CreateAnonymousElement still uses nsIDOMNode, but we should use nsIContent for it.
MozReview-Commit-ID: 2xgzlE6NVra
--HG--
extra : rebase_source : c93a9acb230604da391f705b0038e3cf7fbd4f23
Makoto Kato
Masayuki Nakano
Olli Pettay
Emilio Cobos Álvarez
Bogdan Tara
Ehsan Akhgari
Phil Ringnalda
Nicholas Nethercote
Catalin Badea
Sebastian Hengst