This patch renames:
EditorBase::SplitNode() -> EditorBase::SplitNodeWithTransaction()
EditorBase::SplitNodeDeep() -> EditorBase::SplitNodeDeepWithTransaction()
HTMLEditRules::MaybeSplitAncestorsForInsert() ->
HTMLEditRules::MaybeSplitAncestorsForInsertWithTransaction()
Note it might be that some callers of those methods should be renamed too.
However, we should do it in follow up bug after landing those patches since
we can investigate it with searchfox.org after landing patches.
MozReview-Commit-ID: FfxCfaI85z5
--HG--
extra : rebase_source : 143960de45791c72dbf4d436f65e55452b4f7b10
EditorBase::CreateNode() creates an element node with transaction. I.e., it's
undoable. So, if somebody would use this method as a helper method for changing
the DOM tree, that would cause unexpected undoable transaction. So, we should
make the method name clearer to avoid such bug.
MozReview-Commit-ID: GZsOGBfqog
--HG--
extra : rebase_source : 8b7539a680ee88f3557acb0837fe1a021d842323
So, this patch replaces the setter with non-virtual method and removing the
getter since where is already non-virtual getter method.
MozReview-Commit-ID: Is19Yriz8t8
--HG--
extra : rebase_source : bb2f49f380ddb2e2f96e8690effd8d47d24ae0ae
It is unnecessary to get PresShell for nsStyleText, so we can return bool
instead of nsresult and can change it to static method.
MozReview-Commit-ID: LGrdcaJuLO
--HG--
extra : rebase_source : bb6b6d990741c7b478e9699ae84cc6b89a765bf7
We should not use nsIDOMDocument if unnecessary. Because it needs QI to access
nsIDocument.
MozReview-Commit-ID: CMF3tmvBTB9
--HG--
extra : rebase_source : e832023be8d59a2c1e01bd423e6f058b0708dfe9
To reduce QI, I would like to replace nsIDOMNode with nsINode. And some
parameters in *DataTransder.cpp's methods is unused (it uses as nullptr),
so we should remove these parameters.
Also nsIDOMNodeList is unused now, so we should remove this including.
MozReview-Commit-ID: 1QTIkxDazjJ
--HG--
extra : rebase_source : 3961e897fcaa96975facc822821f1e223cab358d
nsITransactionListener::AddListener() and
nsITransactionListener::RemoveListener() are of course virtual methods.
Additionally, they are safe to call without grabbing the TransactionManager's
instance with local variable. Therefore, if EditorBase has methods to
add/remove transaction listener to/from its transaction manager, we don't
need EditorBase::GetTransactionManager() anymore.
So, this patch adds AddTransactionListener() and RemoveTransactionListener() to
EditorBase and TransactionManager, and remove
EditorBase::GetTransactionManager() (not nsIEditor's one).
MozReview-Commit-ID: FkPa1YgfagD
--HG--
extra : rebase_source : 8ef7796136804e3d7604c5ca5417fb3379606b93
nsIEditor::EnableUndo() and nsITransactionManager::Clear(),
nsITransactionManager::SetMaxTransactionCount() are called a lot but they are
virtual and some of or all of them are called once. There should be each
non-virtual method to do what each root caller wants. Therefore, this patch
adds EditorBase::EnableUndoRedo(), EditorBase::DisableUndoRedo(),
EditorBase::ClearUndoRedo(), TransactionManager::EnableUndoRedo(),
TransactionManager::DisableUndoRedo() and TransactionManager::ClearUndoRedo().
Note that this patch makes TransactionManager won't clear mUndoStack nor
mRedoStack if mDoStack is not empty. This is checked only by
TransactionManager::SetMaxTransactionCount() but according to the comment,
TransactionManager::Clear(), TransactionManager::UndoStack() and
TransactionManager::RedoStack() should check it too.
MozReview-Commit-ID: 6qBZOQNwdhw
--HG--
extra : rebase_source : 3249137f7acca0b4698713ab732774140bcc27e8
Now, both TransactionManager.h and TransactionStack.h are exposed. So,
TransactionManager::GetNumberOfUndoItems() and
TransactionManager::GetNumberOfRedoItems() can be rewritten with non-virtual
inline methods because they just return mUndoStack.GetSize() and
mRedoStack.GetSize(). Then, we can implement EditorBase::NumbeOfUndoItems(),
EditorBase::NumberOfRedoItems(), EditorBase::CanUndo() and
EditorBase::CanRedo() as inline methods.
MozReview-Commit-ID: 3CJd0VrlvFY
--HG--
extra : rebase_source : 6848d80a395f1c161e10bfb50d15bd63de288095
A lot of methods take |const EditorRawDOMPoint&| as their argument. However,
some of them are called with EditorDOMPoint::AsRaw(). This is not good for
performance because:
1. Needs to create temporary instance of EditorRawDOMPoint.
2. EditorRawDOMPoint::AsRaw() may be used by simple mistake.
3. Such methods may call EditorRawDOMPoint::Offset(), however, it's not copied
to the original EditorDOMPoint instance. So, callers may need to compute
offset again.
So, such methods should be changed to template methods if they are not virtual
method and AsRaw() should be gotten rid of for prevent it looking not expensive.
MozReview-Commit-ID: DAqqW4a2EMS
--HG--
extra : rebase_source : 120b920477fe6e7231271411a00994325acdb842
EditorBase::GetStartNodeAndOffset() and EditorBase::GetEndNodeAndOffset() are
just wrappers of EditorBase::GetStartPoint() and EditorBase::GetEndPoint().
They may *compute* offset in the container node even if some callers don't
need the offset. Therefore, we should get rid of them and make all callers
use EditorBase::GetStartPoint() or EditorBase::GetEndPoint() directly.
Note that EditorBase::GetStartNodeAndOffset() and
EditorBase::GetEndNodeAndOffset() returns NS_ERROR_FAILURE if
EditorBase::GetStartPoint() or EditorBase::GetEndPoint() returns not set point.
Therefore, checking the result is set equals checking the old nsresult as
an error.
MozReview-Commit-ID: JLwqRMFLjHC
--HG--
extra : rebase_source : 0eb6bf4ba80e8139c6b9f36723d77d23f2b9099e
It is unnecessary to use already_AddRefed for GetDocument and GetPresShell.
Then, if we remove already_AddRefed, we can replace this with const method.
MozReview-Commit-ID: KTVS0rYrY2i
--HG--
extra : rebase_source : 0199026410fc674f112c960b599a09bc7906cf85
Currently, HTMLEditor doesn't initialize caret position when it gets focus by
itself in most cases. Only when it's in designMode, it may move caret to the
first visible (not checking CSS actually).
In most cases, caret position is adjusted when EditorBase::InitializeSelection()
calls Selection::SetAncestorLimiter(). If selected range is outside of
new limiter, it moves caret to start of the new limiter. However, this is
really different behavior from the other browsers. The other browsers try
to move caret to the first editable text node or before the first editable
content such as <img>, <input>, etc.
This difference causes a serious incompatible issue with Draft.js. It doesn't
initialize caret position when it gets focus but it assumes that caret is
always set to before <br> element if there is no other content.
So, let's try to behave as what other browsers do as far as possible.
This patch makes editor behave as:
* if selection is already in the editing host except start of the editing host,
does nothing.
* if there is non-editable element before any editable node, move caret to
start of the editing host.
* if there is editable text node or element node which cannot have a text node,
move its start or before it.
* if there is no editable nodes which can contain text nodes, move caret to
start of the editing host.
Note that before applying this patch, in designMode, BeginningOfDocument() used
document element instead of <body> element. Therefore, it may set odd position
if <head> element has some text nodes with <script> or <style>. However,
this doesn't make sense and for making more consistent behavior between
designMode and contenteditable, this patch makes it use editing host (it's
<body> element if it's in designMode).
MozReview-Commit-ID: 5neYoTMq6Cc
--HG--
extra : rebase_source : c4d06b6864a221d7cd2833a007d73f7d67821e95
HTMLEditRules::WillInsertBreak() started to use HTMLEditRules::MakeBasicBlock()
to wrap existing inline elements with default paragraph separator if inline
elements are children of editing host. However,
HTMLEditRules::ApplyBlockStyle() called by HTMLEditRules::MakeBasicBlock() sets
mNewNode to last new block node. So, if it wraps inline elements after caret
position, mNewNode becomes after expected caret position and
HTMLEditRules::AfterEditInner() will move caret into it.
This patch make HTMLEditRules::WillInsertBreak() reset mNewNode with
caret position after calling HTMLEditRules::MakeBasicBlock().
Additionally, this patch fixes a bug of HTMLEditor::IsVisibleBRElement().
That is, it uses only editable nodes to check if given <br> element is
visible. However, editable state is not related to this check. If <br>
element is followed by non-editable inline node (except invisible data
nodes), it always visible. This bug caused getting wrong nodes with
HTMLEditRules::GetNodesFromSelection() which is used by
HTMLEditRules::MakeBasicBlock(). Therefore, this patch also adds lots of
EditorBase::Get(Next|Previous)ElementOrText*() and
HTMLEditor::Get(Next|Previous)HTMLElementOrText*() to ignore only invisible
data nodes.
Note that even with this fix, the range of nodes computed by
HTMLEditRules::GetNodesFromSelection() is still odd if only non-editable
elements follow a <br> node which is first <br> element after the caret
position. However, what is expected by the execCommand spec is unclear.
So, automated test added by this patch checks current inconsistent behavior
for now.
MozReview-Commit-ID: 2m52StwoEEH
--HG--
extra : rebase_source : 6b9b2338e35c4d2e89a405fd8e1ffc7b0873ca1e
Since We can use EditorBase/TextEditor/HTMLEditor directly, we can
movei noscript methods in nsIEditor to each class.
Also, Init is unnecessary to use nsIDOMDocument and nsIContent since method
isn't in IDL. And some methods are unused now.
MozReview-Commit-ID: D3B6oSlcT0L
--HG--
extra : rebase_source : 6cab2e6e7b4ba8cfb56d8320be24ca4afcbe55fb
extra : amend_source : 1d8c59086a9158a49dd270b64ecf8341ed4002ce
This patch makes EditorBase derived from nsISelectionListener. Then, we can
make IMEContentObserver, TextInputListener, ComposerCommandsUpdater,
TypeInState not derived from nsISelectionListener since EditorBase or
HTMLEditor can notify them of selection change directly. Additionally,
ResizerSelectionListener is not necessary anymore since it just implements
nsISelectionListener and calls only a method of HTMLEditor. So, HTMLEditor
can call it directly.
Note that the order of selection listeners may be different. However,
according to what each selection listener does, changing the order isn't
problem.
MozReview-Commit-ID: 1JXZxQcS0tP
--HG--
extra : rebase_source : c2ebe622a74001ad4e421da492dcdab8e6fe1649
Similar to TextInputListener, EditorBase should store IMEContentObserver
directly instead of via nsIEditorObserver. Then,
EditorBase::NotifyEditorObservers() can call each method directly.
Additionally, we can make IMEContentObserver not derived from nsIEditorObserver.
MozReview-Commit-ID: cNKWJe5eUC
--HG--
extra : rebase_source : 4ed3b3b3180b8ee4a7c514ce1f89eba4dad64fbe
Now, EditorBase can store TextInputListener directly instead of as
nsIEditorObserver. And then, EditorBase can call its EditAction() method
directly. Therefore, we can make TextInputListener not derived from
nsIEditorObserver.
MozReview-Commit-ID: 4qPnnvReLKy
--HG--
extra : rebase_source : cde47e245c9856abf696dbaf8e26d8e4d6d98d42
Currently, first edit action listener is always TextServicesDocument for
EditorBase::mInlineSpellChecker if spell check is enabled and it requires
only DidDeleteNode() and DidJoinNodes(). So, in most cases, EditorBase
should call only them to avoid running redundant for loops for
nsIEditActionListener methods.
This patch makes that EditorBase::AddEditActionListener() and
RemoveEditActionListener() check whether coming nsIEditActionListener is
TextServicesDocument for mInlineSpellChecker. If so, EditorBase should
store it as reference to TextServicesDocument. And when edit action occurs,
its DidDeleteNode() and DidJoinNodes() should be called directly.
Unfortunately, this patch makes TextServiceDocument's maintaining rules
complicated. However, it must be really rare case to add new edit action
listener because it's really old component.
Note that EditorSpellCheck may be created multiple instances for an editor
from chrome JS. Therefore, we need to keep TextServicesDocument being
derived from nsIEditActionListener because in such case, TextServicesDocument
for other EditorSpellCheck instances should be supported via
nsIEditActionListener even though such case makes EditorBase slower.
MozReview-Commit-ID: KtlXsBCOzKL
--HG--
extra : rebase_source : 6827ed09a028f2049fd7afba2f5116d092bd14e5
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
HTMLEditRules implements only some of nsIEditActionListener and this is always
first edit action listener. So, if we make EditorBase treat HTMLEditRules
directly before notifying edit action listeners, we can save a lot of runtime
cost (virtual calls especially unnecessary, copying array of edit action
listeners with strong pointer, redundant QIs), although the code becomes not
beautiful.
Perhaps, we should do same thing to nsTextServicesDocument and
mozInlineSpellChecker in other bugs.
MozReview-Commit-ID: Eveaxj398f2
--HG--
extra : rebase_source : 0b7b66ba1002e08591e8d95ef68b216e7ce1f93b
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
This patch creates factory methods for AddStyleSheetTransaction and
RemoveStyleSheetTransaction, and removes EditorBase::CreateTxnForAddStyleSheet()
and EditorBase::CreateTxnForRemoveStyleSheet() instead.
MozReview-Commit-ID: 6dnZctDtNik
--HG--
extra : rebase_source : 43eaadbde06e4a0b061ea8136e12ffeccfaf5592
This patch creates two factory methods of ChangeAttributeTransaction. One is
for setting an attribute to specific value. The other is for removing an
attribute. So, EditorBase::CreateTxnForSetAttribute() and
EditorBase::CreateTxnForRemoveAttribute() are unnecessary anymore.
MozReview-Commit-ID: 2fEVd3pDXsf
--HG--
extra : rebase_source : 674005a5b9fc623999a0f51dc8697027970f06c9
EditorBase::CreateTxnForJoinNode() just hides what it does.
For making the caller clearer, let's create a factory method,
JoinNodeTransaction::MaybeCreate().
MozReview-Commit-ID: 8vADXdzMeuV
--HG--
extra : rebase_source : 6a281aff11bfa019c292d26cadd0cd29da12753f
SplitNodeTransaction::Create() just hides what it does. For making its caller
clearer, let's create a factory method, SplitNodeTransaction::Create().
MozReview-Commit-ID: KDiC8dDrLuQ
--HG--
extra : rebase_source : ac04544e10644b8a73375fb2b786e0bc86eb56ae
EditorBaseTransaction::CreateTxnForDeleteNode() just hides what it does.
Instead, let's create a factory method, DeleteNodeTransaction::MaybeCreate()
for making callers clearer.
MozReview-Commit-ID: 8WUYN0BjKSU
--HG--
extra : rebase_source : e0ff8b8434b720dc124c770cd7371d84b949ca8d
DeleteTextTransaction should have 3 factory methods. One is, simply to create
an instance with a pair of offset and length. The others are, to create an
instance for deleting a previous or next character at offset.
The former was EditorBase::CreateTxnForDeleteText() and the latter was
EditorBase::CreateTxnForDeleteCharacter(), but this patch creates
DeleteTextTransaction::MaybeCreate() for the former,
DeleteTextTransaction::MaybeCreateForPreviousCharacter() and
DeleteTextTransaction::MaybeCreateForNextCharacter() for the latter.
MozReview-Commit-ID: DFELbmAJDo3
--HG--
extra : rebase_source : 1600984c704b460e1cc09777b81df2906c154cce
EditorBase::CreateTxnForComposition() just hides what it does. For its caller,
creating a factory method, CompositionTransaction::Create(), is clearer what
it does.
Additionally, capsuling the creation in CompositionTransaction class can make
the text node information in TextComposition updated automatically. So, now,
it might be better to update them in DoTransaction() because there is a lag
between creating the transaction and calling DoTransaction(). However, this
patch doesn't want to change any existing behavior. So, this doesn't fix this
issue.
MozReview-Commit-ID: K8ci7ytwh1u
--HG--
extra : rebase_source : d468a0fc997c99f78f7eb46451082e7f1e052890
EditorBase::CreateTxnForCreateElement() just hides what it does. Let's make
the caller what it does with creating CreateElementTransaction::Create().
MozReview-Commit-ID: DYcfQV6KiUZ
--HG--
extra : rebase_source : d3f31b8db92bd3b2af464c66e064dd7b21018960
EditorBase::CreateTxnForInsertNode() just hides what it does. Let's create
InsertNodeTransaction::Create() and make the caller clearer.
MozReview-Commit-ID: 2J2WV73cdsm
--HG--
extra : rebase_source : 15b6391aee5beca4401e7c7a4ee8bf350a7590fd
EditorBase::CreateTxnForInsertText() just hides what it exactly does.
Rewriting it with a static factory method, InsertTextTransaction::Create()
should be clearer for its caller.
MozReview-Commit-ID: Er7Zlhtbnb0
--HG--
extra : rebase_source : 9dc71b3baab839f61153b96806fac5baae5d46cb
The only caller is HTMLEditor::IsEmptyNodeImpl(). So, we can get rid of it.
MozReview-Commit-ID: GTJiXwSCrwM
--HG--
extra : rebase_source : a44b277547d0641f244ff363f5cde8ae44b13eda
EditorBase stores a text node, offset in it and length in it of composition
string directly. However, this wastes memory space if user never uses IME
or user only sometimes uses IME. Additionally, storing all data in
TextComposition is better than current design when other classes like
CompositionTransaction wants some information of both EditorBase and
TextComposition.
This patch moves those 3 members from EditorBase to TextComposition.
MozReview-Commit-ID: 4N7wmGGfxmt
--HG--
extra : rebase_source : bd7cb37fe9631b959ec21da40c20751fec269dca
Different from RangeBoundaryBase, EditorDOMPointBase can store only child node.
I.e., mOffset may be invalid until its Offset() is called. So,
GetChildAtOffset() isn't good name. It should be just GetChild().
Similarly, GetNextSiblingOfChildAtOffset() and
GetPreviousSiblingOfChildAtOffset() should be renamed to GetNextSiblingOfChild()
and GetPreviousSiblingOfChild().
MozReview-Commit-ID: WpkPmDwkrL
--HG--
extra : rebase_source : 2be1fcbee129f4c96e9b166be5a924845340708f
EditorBase::CreateTxnForInsertNode() and EditorBase::InsertNode() should take
|const EditorRawDOMPoint&| as an argument specifying point to insert.
MozReview-Commit-ID: KhK19xS7wXb
--HG--
extra : rebase_source : f7b08b7d049eef8a9c03ee681e53e8d469915b15
While moving children of a container to another container, mutation observer
may move children before moving and/or move node immediately after the
insertion point. Therefore, EditorBase should store all children which
should be moved with a local variable. Then, move one by one carefully.
E.g., if a child before being moved is moved to different container, it
shouldn't be moved because JS already handles it as expected for the web
app. If next sibling of the insertion point has been moved, EditorBase
should stop moving the remaining children because it may move children to
odd position and it may cause dataloss.
This patch creates EditorBase::MoveChildren() and it moves children carefully
with above checks. Additionally, making its callers simpler, this patch also
creates EditorBase::MovePreviousSiblings() and MoveAllChildren().
MozReview-Commit-ID: FJDdSqXIlqD
--HG--
extra : rebase_source : 54bded29dbbd9547339a2c6e1a1264e22fbdc740
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
First of all, this patches fixes a bug of EditorBase::CreateNode(). It takes
|EditorRawDOMPoint&| but it should be |const EditorRawDOMPoint&| for making
callers can specify temporary instances.
Next, this patch creates |SplitNodeResult| stack class for result of
EditorBase::SplitNodeDeep(). SplitNodeDeep() needs to return previous node
and next node of split point. They are called as left node and right node,
but these calls are really different term usage. Therefore, this patch names:
aOutLeftNode -> SplitNodeResult::GetPreviousNode()
aOutRightNode -> SplitNodeResult::GetNextNode()
and also declares SplitNodeResult::GetLeftNode() and
SplitNodeResult::GetRightNode() which are same meaning as left/right node of
other splitting methods.
Additionally, of course, this patch makes SplitNodeDeep() use
|const EditorRawDOMPoint&| to receive the start point of right node.
MozReview-Commit-ID: FnJpeKgtzm4
--HG--
extra : rebase_source : 3829e5528ef837b13fed305e0df1dbbf00e02a07
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
EditorBase::CreateTxnForSplitNode() and EditorBase::SplitNode() takes a set of
container and offset in it for specifying a point to split.
Instead, they should take EditorRawDOMPoint for specifying start of right node.
MozReview-Commit-ID: 5VwS8oudzIT
--HG--
extra : rebase_source : 727948e5cf95f0713019f57ae9a007b85569fa56
EditorBaseSplitNodeImpl() should be clean up with EditorDOMPoint which should
be an argument to point the first point of right node (existing split node).
MozReview-Commit-ID: DN0yHm9G9yT
--HG--
extra : rebase_source : 256b4e2125e831b7be9e5c4aefc6f04c80e3c1f5
An overload of EditorBase::GetNextNode() takes a set of container, child node
and offset of the child in the container. Replacing it with EditorRawDOMPoint
makes the caller simpler.
Additionally, it has two bool arguments, one is for searching if editable node,
the other is for searching if in same block. So, they can be hidden with
some human readable inline methods.
When I was creating this patch, I realized that
GetNextNodeInternal(const EditorRawDOMPoint& aPoint) may return
aPoint.GetChildAtOffset(). I.e., it starts to search from the specified point
rather than next node. On the other hand, GetNextNodeInternal(nsINode& aNode)
never returns aNode itself. So, it there is better name instead of "Next",
we should take it. But I have no better idea. So, this patch just explains
the difference with comments in EditorBase.h.
MozReview-Commit-ID: 4Lb6o9SJuhy
--HG--
extra : rebase_source : d20d728eae69659ef448b6679ae8f73d64c2d7e9
An overload of EditorBase::GetPriorNode() takes a set of container, child node
and offset of the child in the container. Replacing it with EditorRawDOMPoint
makes the caller simpler.
Additionally, it has two bool arguments, one is for searching if editable node,
the other is for searching if in same block. So, they can be hidden with
some human readable inline methods.
Finally, "Prior" isn't a term of DOM. So, let's use "Previous" instead.
MozReview-Commit-ID: A9uKzHaikY9
--HG--
extra : rebase_source : 15bfdfde0ad89a5331d6c8a24351741eeef476d5
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
EditorBase::FindBetterInsertionPoint() now use 3 in/out arguments. This is
really ugly and making the callers hard to read. So, let's make it take an
argument whose type is |const EditorRawDOMPoint&| and return other
EditorRawDOMPoint instance.
Additionally, this fixes bugs of text node length checks in the method.
Basically, this shouldn't affect to any actual behavior, though. That is
because text node shouldn't be able to have string longer than INT32_MAX.
MozReview-Commit-ID: FClUQSJzd8c
--HG--
extra : rebase_source : 3e2fbd345015f7068c7e35a94c31731e7936009f
EditorBase::CreateNode() should take EditorRawDOMPoint as insertion point of
the new element instead of a set of container, child and offset of the child
in the container.
This patch initializes EditorRawDOMPoint with original 3 arguments as far as
possible. If the relation of them are broken, MOZ_ASSERT in RawRangeBoundary
constructor detects existing bugs.
MozReview-Commit-ID: 2N55S6pRv7k
--HG--
extra : rebase_source : 2b14a7715815ca0007635b8f791ca9edbe5b65f1
The constructor of CreateElementTransaction now takes EditorRawDOMPoint instead
of a set of container node and offset in it. So, its only user,
EditorBase::CreateTxnForCreateElement(), should take EditorRawDOMPoint too.
MozReview-Commit-ID: A8QfPM3LRii
--HG--
extra : rebase_source : 4a99e5cb58230649d19faca788a330fe02eb6bb1
A lot of methods in editor returns a child offset with an out param when it
returns its container and offset in the container. This is ugly hack for
performance of nsINode::IndexOf(). However, there are a lot of regression
since the relation between offset and child node can be broken really easily.
So, we should make EditorDOMPoint as a subclass of RangeBoundary and manage
a set of container, reference child and its offset in it (e.g.,
SetNextSibling() added by this patch).
Note that RangeBoundary's performance is not good for temporary use if we set
a point with offset, it immediately retrieves mRef. The following patch will
improve this performance.
MozReview-Commit-ID: 7mcJ1P1OjVr
--HG--
rename : editor/libeditor/EditorUtils.h => editor/libeditor/EditorDOMPoint.h
extra : rebase_source : 785094fcfc592d9e5b48cbc36ed225dbb8bb4111
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
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
In the old design, EditorBase::mRootElement is initialized when
nsIEditor::GetRootElement() is called. Therefore, EditorBase::GetRoot()
calls if mRootElement is nullptr.
However, mRootElement is now initialized when EditorBase::UpdateRootElement()
is called and it's always initialized when EditorBase::Init() is called.
So, EditorBase::GetRoot() doesn't need to call nsIEditor::GetRootElement()
anymore.
MozReview-Commit-ID: 6dNEJaGNMZe
--HG--
extra : rebase_source : ed29488cfd1434fb200387706ca5a96cb2185090
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
nsTextFrame stores text as single byte character array if all characters are
less than U+0100. Although, this saves footprint, but retrieving and modifying
text needs converting cost. Therefore, if it's created for a text node in
<input> or <textarea>, it should store text as char16_t array.
MozReview-Commit-ID: 9Z82rketT7g
--HG--
extra : rebase_source : 59f59ac1488c21a57d95d253cc794a011d672c95
EditorBase::GetSelection() sometimes appears in profile. So, it shouldn't be
called in nsIEditor::EndOfDocument() if the callers of
nsIEditor::EndOfDocument() has a pointer to Selection.
This patch adds EditorBase::CollapseSelectionToEnd() for the internal method
and make all callers of nsIEditor::EndOfDocument() use it.
MozReview-Commit-ID: 8H4ThxzdKDf
--HG--
extra : rebase_source : 7436d7f286351fa9c91175b40e686f7ca1f3c69f
nsINode::IndexOf() is expensive especially when it's in a hot path, it's too
expensive. So, EditorBase::GetChildOffset() and EditorBase::GetNodeLocation()
should check child's siblings first. If some of them are nullptr, it means
that it's first child or last child of the parent.
Note that EditorBase::GetChildOffset() may return wrong index if it's called
while aChild is being removed from aParent or aParent isn't actual parent of
aChild. However, there are MOZ_ASSERTs to ensure value isn't -1. Therefore,
it's safe to assume that aParent is always the parent of aChild and it won't
be called from ContentRemoved() of mutation observers.
MozReview-Commit-ID: 8JdYWuZbHe5
--HG--
extra : rebase_source : 6ded91a3aa8b00ab4d2d544c2c392d88cb769cef
AutoPlaceHolderBatch can take EditorBase class and its inherited class, AutoEditBatch, can be removed if we implement other constructor which doesn't take transaction name.
Additionally, nsIEditor::(Begin|End)PlaceHolderTransaction() are referred only by AutoPlaceHolderBatch. Therefore, they can be non-public methods and removed from nsIEditor interface.
Note that this patch also repalces "PlaceHolder" with "Placeholder" since it's a word.
MozReview-Commit-ID: 5dw3kcX3bOx
--HG--
extra : rebase_source : e926cc1c2ebea70eb08e43778a8b52912b559b7b
EditorCommands implements common edit commands. So, we can use TextEditor even if the instance is HTMLEditor.
Then, EditorCommands can use non-virtual methods of the concrete classes.
MozReview-Commit-ID: DgKHqC0osRb
--HG--
extra : rebase_source : e9abd7ef8b48cfdc65bbeb56ebe81dc0548005dd
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
This method can be extremely hot, so we need to remove all sources of XPCOM
overhead from it. This includes the usages of weak pointers (thanks to the
previous parts), refcounting, and QueryInterface.
I kept the callers hold the selection controller alive by assigning the
return value to an nsCOMPtr in places where the methods called on it could
have a remote chance of messing with the lifetime of objects.
Besides some unnecessary copying and malloc overhead that this removes, it
also removes a call to dom::Text::GetData() which we used to only make to
get the old length of the text node before modifying it. Turns out that
this old length was already obtained once in SetTextImpl().
HTMLEditor::TabInTable inserts row element, then it selects a cell. But when enabling lazy frame construction for editable node, it selects invalid cell and table.
Because HTMLEditor::SetSelectionAfterTableEdit doesn't select cell correctly on InsertTableRow().
HTMLEditor::SetSelectionAfterTableEdit uses HTMLEditor::GetCellAt, so it depends on frame. So we need flush frame before calling it.
Also, a comment of HTMLEditor::InsertTableRow is invalid now because we don't use nsresult version of CreateElementWithDefualts.
MozReview-Commit-ID: 698TvmMZgwB
--HG--
extra : rebase_source : 95df12f1f870a2c68d02b24b8758dfe6d381a416
Masayuki Nakano
Dorel Luca
Boris Zbarsky
Makoto Kato
Olli Pettay
Emilio Cobos Álvarez
Ehsan Akhgari
Phil Ringnalda
Nicholas Nethercote
Eric Rahm