searching for reviewer(m_kato)
42ee22b7ad56: Bug 1460527 - Add Symbola to the common fallbacks list on Linux, to reduce the probability of falling back to the color-emoji font when emoji-style rendering is not actually wanted. r=m_kato, a=RyanVM
Jonathan Kew <jkew@mozilla.com> - Wed, 20 Jun 2018 19:47:08 +0100 - rev 473790
Push 1737 by ryanvm@gmail.com at 2018-07-02 16:05 +0000
Bug 1460527 - Add Symbola to the common fallbacks list on Linux, to reduce the probability of falling back to the color-emoji font when emoji-style rendering is not actually wanted. r=m_kato, a=RyanVM
09928d75cfec: Bug 1456381 - TSFTextStore should discard pending composition update actions before recording composition end action r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 19 Apr 2018 20:42:00 +0900 - rev 471560
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1456381 - TSFTextStore should discard pending composition update actions before recording composition end action r=m_kato TSFTextStore should discard pending composition update actions when it records end composition update action because end composition update action causes dispatching eCompositionCommit event and it replaces old composition string anyway. So, following eCompositionChange which is dispatched by preceding composition update actions are just redundant. MozReview-Commit-ID: HBHx2jA15ro
77e5d42d7d55: Bug 1456377 - Move composition event handlers from EditorBase to TextEditor r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 19 Apr 2018 00:31:51 +0900 - rev 471373
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1456377 - Move composition event handlers from EditorBase to TextEditor r=m_kato Currently, EditorBase handles most composition events. However, only eCompositionChange event handler is in TextEditor and it's the main event of handling composition. Therefore, we should make all composition event handlers in one place for easier to read, and make them non-virtual. MozReview-Commit-ID: BYDhiPyGKvo
be5ba8b6dea2: Bug 1455903 - Make EditorBase::CloneAttributesWithTransaction() set sourceElement to aSourceElement rather than aDestElement r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 23 Apr 2018 18:02:50 +0900 - rev 471352
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1455903 - Make EditorBase::CloneAttributesWithTransaction() set sourceElement to aSourceElement rather than aDestElement r=m_kato This is simple mistake of bug 1451672. EditorBase::CloneAttributesWithTransaction() sets both sourceElement and destElement to aDestElement, but of course, it should set sourceElement to aSourceElement. Additionally, this patch adds mozilla specific web-platform tests to check attribute cloning with basic edit operation. MozReview-Commit-ID: GM1VjRHG7C3
4ac461885d8c: Bug 1454126 - HTMLEditor should adjust selection outside native anonymous subtree when it inserts something at selection r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 17 Apr 2018 17:01:57 +0900 - rev 471106
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1454126 - HTMLEditor should adjust selection outside native anonymous subtree when it inserts something at selection r=m_kato HTMLEditor::InsertElementAtSelection() doesn't check if selection is in native anonymous subtree. Therefore, it could insert element into <input> element etc. This patch adds new API to EditorDOMPointBase to compute ancestor point which is not in native-anonymous subtree and make HTMLEditor::GetBetterInsertionPointFor() use it to not return point in any native-anonymous subtrees.
6a2fca281629: Bug 1451672 - part 24: Rename HTMLEditor::CopyLastEditableChildStyles() to HTMLEditor::CopyLastEditableChildStylesWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 17 Apr 2018 01:15:23 +0900 - rev 470925
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 24: Rename HTMLEditor::CopyLastEditableChildStyles() to HTMLEditor::CopyLastEditableChildStylesWithTransaction() r=m_kato Like this adds new comments into the method, we should optimize the method since it may create a lot of transactions and dispatch a lot of mutation events. MozReview-Commit-ID: FknJfu6QCjS
6ce44677c7eb: Bug 1451672 - part 23: Rename HTMLEditor::Set*BackgroundColor() to HTMLEditor::Set*BackgroundColorWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 17 Apr 2018 00:02:39 +0900 - rev 470924
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 23: Rename HTMLEditor::Set*BackgroundColor() to HTMLEditor::Set*BackgroundColorWithTransaction() r=m_kato MozReview-Commit-ID: 7kUahOPZCwE
7b6165489943: Bug 1451672 - part 22: Rename HTMLEditor::InsertNodeIntoProperAncestor() to HTMLEditor::InsertNodeIntoProperAncestorWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 16 Apr 2018 23:53:46 +0900 - rev 470923
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 22: Rename HTMLEditor::InsertNodeIntoProperAncestor() to HTMLEditor::InsertNodeIntoProperAncestorWithTransaction() r=m_kato MozReview-Commit-ID: 6O47YeSpud8
ec93f6db7e4b: Bug 1451672 - part 21: Refine TextEditor::TypedText() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 16 Apr 2018 23:43:36 +0900 - rev 470922
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 21: Refine TextEditor::TypedText() r=m_kato According to existing comments, TextEditor::TypedText() and HTMLEditor::TypedText() are intentional bottleneck to debug. However, only for that purpose, it and its internal methods are made virtual. This really doesn't make sense. So, this patch creates TextEditor::OnInputText() for callers of TypedText() with non-empty string, TextEditor::OnInputParagraphSeparator() for callers of TypedText() with eTypeBreak (Enter key or insertParagraphSeparator), HTMLEditor::OnInputLineBreak() for callers of TypedText() with eTypeBR (Shift + Enter or insertLineBreak). Additionally, this creates internal non-virtual methods for XPCOM methods which are used as internal methods of TypedText(). One is InsertTextAsAction() for nsIPlatintextEditor.insertText(). the other is InsertParagraphSeparator() for nsIPlaintextEditor.insertLineBreak(). Although those new methods are not have "WithTransaction" postfix, they must be clearer they'll use transactions since user input and actions should be undo-able. MozReview-Commit-ID: AmOkMqovIKA
5726deba8028: Bug 1451672 - part 20: Rename HTMLEditor::MakeDefinitionItem() and HTMLEditor::InsertBasicBlock() with "WithTransaction" postfix r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 16 Apr 2018 20:33:27 +0900 - rev 470921
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 20: Rename HTMLEditor::MakeDefinitionItem() and HTMLEditor::InsertBasicBlock() with "WithTransaction" postfix r=m_kato MozReview-Commit-ID: 2D50suUnFcw
9617921cebc3: Bug 1451672 - part 19: Remove TextEditor::CreateBR() and rename TextEditor::CreateBRImpl() to TextEditor::InsertBrElementWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 16 Apr 2018 19:21:29 +0900 - rev 470920
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 19: Remove TextEditor::CreateBR() and rename TextEditor::CreateBRImpl() to TextEditor::InsertBrElementWithTransaction() r=m_kato TextEditor::CreateBR() is just a wrapper of TextEditor::CreateBRImpl() for automatically retrieving Selection of the editor. And TextEditor::CreateBRImpl() should be renamed to TextEditor::InsertBrElementWithTransaction() for making it clearer what it does. MozReview-Commit-ID: D8sjVdLrVrd
907f07168fed: Bug 1451672 - part 18: Rename EditorBase::CloneAttributes() to EditorBase::CloneAttributesWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 13 Apr 2018 18:44:08 +0900 - rev 470919
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 18: Rename EditorBase::CloneAttributes() to EditorBase::CloneAttributesWithTransaction() r=m_kato MozReview-Commit-ID: 5tL31gRDVc9
a6d341deddb0: Bug 1451672 - part 17: Rename EditorBase::InsertContainerAbove() to EditorBase::InsertContainerWithTransactionInternal() and wraps it with new inline methods, EditorBase::InsertContainerWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 13 Apr 2018 18:17:04 +0900 - rev 470918
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 17: Rename EditorBase::InsertContainerAbove() to EditorBase::InsertContainerWithTransactionInternal() and wraps it with new inline methods, EditorBase::InsertContainerWithTransaction() r=m_kato Similar to EditorBase::ReplaceContainerWithTransaction(), EditorBase::InsertContainerAbove() may set an attribute to newly created element if it's specified. However, for avoiding the null check, let's make them as references rather than pointers and treat nsGkAtoms::_empty as nullptr for making the code safer. This patch removes "Above" from the method name since it's redundant. "Insert" sounds like inserting a node, and "Container" means to keep existing children with new element in EditorBase. MozReview-Commit-ID: 6EnkKHynYSP
1871811c637d: Bug 1451672 - part 16: Rename EditorBase::MoveNode() to EditorBase::MoveNodeWithTransaction() and create EditorBase::MoveNodeToEndWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 12 Apr 2018 23:58:52 +0900 - rev 470917
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 16: Rename EditorBase::MoveNode() to EditorBase::MoveNodeWithTransaction() and create EditorBase::MoveNodeToEndWithTransaction() r=m_kato This patch renames EditorBase::MoveNode() to EditorBase::MoveNodeWithTransaction() and redesign its parameters including replacing a set of container node and offset in it to EditorDOMPointBase. However, it takes magic number -1 as meaning end of the container. Therefore, this patch adds MoveNodeToEndWithTransaction() for keeping the callers simple. MozReview-Commit-ID: BeTq5c7GQNN
3bd18c2b9851: Bug 1451672 - part 15: Rename EditorBase::RemoveContainer() and HTMLEditor::RemoveBlockContainer() with "WithTransaction" postfix and make their argument |Element&| r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 12 Apr 2018 22:23:04 +0900 - rev 470916
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 15: Rename EditorBase::RemoveContainer() and HTMLEditor::RemoveBlockContainer() with "WithTransaction" postfix and make their argument |Element&| r=m_kato MozReview-Commit-ID: 2toj48mqHM9
24e17127ec48: Bug 1451672 - part 14: Rename EditorBase::ReplaceContainer() to EditorBase::ReplaceContainerWithTransactionInternal() and create some wrappers of it r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 12 Apr 2018 21:45:55 +0900 - rev 470915
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 14: Rename EditorBase::ReplaceContainer() to EditorBase::ReplaceContainerWithTransactionInternal() and create some wrappers of it r=m_kato The parameters of EditorBase::ReplaceContainer() are complicated. For example, if it's specified as cloning all attributes, aAttribute and aValue are ignored because CloneAttributes() removes all existing attributes but ReplaceContainer() sets attributes before calling CloneAttributes(). This method has 3 modes: 1. Just replaces aOldContainer with new element. 2. #1 and clones all attributes from aOldContainer to the new element. 3. #1 and sets aAttribute of the new element to aValue. Therefore, this patch creates 3 inline wrappers of the renamed method. MozReview-Commit-ID: IsPu2uZuU8f
979bfcb75157: Bug 1451672 - part 13: Rename EditorBase::InsertTextImpl() and EditorBase::InsertTextIntoTextNodeImpl() to EditorBase::InsertTextWithTransaction() and EditorBase::InsertTextIntoTextNodeWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 12 Apr 2018 17:58:14 +0900 - rev 470914
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 13: Rename EditorBase::InsertTextImpl() and EditorBase::InsertTextIntoTextNodeImpl() to EditorBase::InsertTextWithTransaction() and EditorBase::InsertTextIntoTextNodeWithTransaction() r=m_kato MozReview-Commit-ID: DF3HBVyu4P2
4b372e4cc463: Bug 1451672 - part 12: Create HTMLEditor::RemoveStyleSheetWithTransaction() as implementation of nsIEditorStyleSheets::RemoveStyleSheet() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 12 Apr 2018 17:20:21 +0900 - rev 470913
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 12: Create HTMLEditor::RemoveStyleSheetWithTransaction() as implementation of nsIEditorStyleSheets::RemoveStyleSheet() r=m_kato MozReview-Commit-ID: BIXU3jzD1rU
407654389402: Bug 1451672 - part 11: Rename EditorBase::SetAttribute(), EditorBase::RemoveAttribute() and EditorBase::CloneAttribute() with "WithTransaction" postfix r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 12 Apr 2018 16:58:33 +0900 - rev 470912
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 11: Rename EditorBase::SetAttribute(), EditorBase::RemoveAttribute() and EditorBase::CloneAttribute() with "WithTransaction" postfix r=m_kato MozReview-Commit-ID: I8T9MNkY8Yq
81798a8610e1: Bug 1451672 - part 10: Rename TextEditor::DeleteSelectionImpl() to TextEditor::DeleteSelectionWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 11 Apr 2018 19:11:15 +0900 - rev 470911
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 10: Rename TextEditor::DeleteSelectionImpl() to TextEditor::DeleteSelectionWithTransaction() r=m_kato MozReview-Commit-ID: 8nypHV8X3js
585bed4748a7: Bug 1451672 - part 9: Create TextEditor::DeleteSelectionAsAction() as implementation of nsIEditor::DeleteSelection() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 11 Apr 2018 17:37:49 +0900 - rev 470910
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 9: Create TextEditor::DeleteSelectionAsAction() as implementation of nsIEditor::DeleteSelection() r=m_kato First, EditorBase::DeleteSelection() is never used since TextEditor::DeleteSelection() overrides it but does not call it. So, this patch makes EditorBase::DeleteSelection() only returns NS_ERROR_NOT_IMPLEMENTED. Next, EditorBase::DeleteSelectionImpl() actually removes content for TextEditor::DeleteSelection(). So, it should be named as DeleteSelectionWithTransaction(). However, it'll be done in the following patch. On the other hand, its callers are EditorBase::HandleKeyPressEvent() and EditorBase::DeleteSelectionAndPrepareToCreateNode(). Fortunately, they can be moved to TextEditor simply. Therefore this patch moves the methods to TextEditor for making related methods in a place. Then, we can make the implementation of nsIEditor::TextEditor() as a non-virtual method, TextEditor::DeleteSelectionAsAction(). MozReview-Commit-ID: KXFDhW3G9lA
5e8f25ef1174: Bug 1451672 - part 8: Rename EditorBase::DeleteText() to EditorBase::DeleteTextWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 10 Apr 2018 16:50:06 +0900 - rev 470909
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 8: Rename EditorBase::DeleteText() to EditorBase::DeleteTextWithTransaction() r=m_kato MozReview-Commit-ID: KK4dTpKbpLc
81a8389b9daa: Bug 1451672 - part 7: Rename EditorBase::DeleteNode() to EditorBase::DeleteNodeWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 10 Apr 2018 16:23:54 +0900 - rev 470908
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 7: Rename EditorBase::DeleteNode() to EditorBase::DeleteNodeWithTransaction() r=m_kato MozReview-Commit-ID: AQVVTjfXJv
28422b0eee9a: Bug 1451672 - part 6: Rename EditorBase::JoinNodesImpl() to EditorBase::DoJoinNodes() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 10 Apr 2018 03:56:46 +0900 - rev 470907
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 6: Rename EditorBase::JoinNodesImpl() to EditorBase::DoJoinNodes() r=m_kato MozReview-Commit-ID: 9fqa4fKkAF5
5f61649cdc96: Bug 1451672 - part 5: Rename EditorBase::JoinNodes() and related methods with "WithTransaction" postfix r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 10 Apr 2018 03:46:44 +0900 - rev 470906
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 5: Rename EditorBase::JoinNodes() and related methods with "WithTransaction" postfix r=m_kato This patch renames: EditorBase::JoinNodes() -> EditorBase::JoinNodesWithTransaction() EditorBase::JoinNodeDeep() -> EditorBase::JoinNodesDeepWithTransaction() HTMLEditRules::JoinNodesSmart() -> HTMLEditRules::JoinNearestEditableNodesWithTransaction() HTMLEditRules::TryToJoinBlocks() -> HTMLEditRules::TryToJoinBlocksWithTransaction() MozReview-Commit-ID: Ao16GhAcyIZ
1f538ba260f8: Bug 1451672 - part 4: Rename EditorBase::SplitNodeImpl() to EditorBase::DoSplitNode() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 10 Apr 2018 02:32:33 +0900 - rev 470905
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 4: Rename EditorBase::SplitNodeImpl() to EditorBase::DoSplitNode() r=m_kato EditorBase::SplitNodeImpl() is called by SplitNodeTransaction::DoTransaction() for actually splitting a node. However, "WithoutTransaction" postfix is really redundant. Perhaps, just naming DoSplitNode() is better since "Impl" isn't unclear and not useful if somebody wants to use it as a utility method and there has already been EditorBase::SplitNode() which is an override of nsIEditor::SplitNode(). It must not be good to use same name for different purpose (EditorBase::SplitNode() creates a transaction). MozReview-Commit-ID: Akjeyp52vVv
6c75071ac1bb: Bug 1451672 - part 3: Rename EditorBase::SplitNode() and related methods to ending with "WithTransaction" r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 10 Apr 2018 02:16:49 +0900 - rev 470904
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 3: Rename EditorBase::SplitNode() and related methods to ending with "WithTransaction" r=m_kato 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
ef997456c777: Bug 1451672 - part 2: Rename EditorBase::InsertNode() to EditorBase::InsertNodeWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 10 Apr 2018 01:34:29 +0900 - rev 470903
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 2: Rename EditorBase::InsertNode() to EditorBase::InsertNodeWithTransaction() r=m_kato MozReview-Commit-ID: 4n5EVvUKrux
16bc145641f9: Bug 1451672 - part 1: Rename EditorBase::CreateNode() to EditorBase::CreateNodeWithTransaction() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 10 Apr 2018 01:17:26 +0900 - rev 470902
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1451672 - part 1: Rename EditorBase::CreateNode() to EditorBase::CreateNodeWithTransaction() r=m_kato 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
85df37b45c47: Bug 1454573 - Update languageNames.properties with missing locales: crh, mai, meh, mix r=m_kato
Francesco Lodolo (:flod) <flod@lodolo.net> - Thu, 19 Apr 2018 11:50:19 +0200 - rev 470724
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1454573 - Update languageNames.properties with missing locales: crh, mai, meh, mix r=m_kato Also add missing locales to langGroups.properties (an, ast, az, uz) and language.properties (son) MozReview-Commit-ID: 2dAOly4wxHm
c2bc44fd23ad: Bug 1454945 - Get rid of nsIEditor.suppressDispatchingInputEvent since nobody uses it from JS r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 18 Apr 2018 22:57:41 +0900 - rev 470721
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1454945 - Get rid of nsIEditor.suppressDispatchingInputEvent since nobody uses it from JS r=m_kato 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
bc6e8d505359: Bug 1453872 - Make HTMLEditRules::JoinNodesSmart() return { aRightNode - aLeftNode.Length() } by default r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 13 Apr 2018 13:18:13 +0900 - rev 469519
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1453872 - Make HTMLEditRules::JoinNodesSmart() return { aRightNode - aLeftNode.Length() } by default r=m_kato This is regression of bug 1423835. When I fixed the bug, I accidentally changed the result of HTMLEditRules::JoinNodesSmart() to use new API. However, it was simple misunderstand. The original code sets the initial value of result to { aRightNode - aLeftNode.Length() } but I understood it as { aRightNode - aRightNode.Length() }. Therefore, this patch backs out the patch only for this line. MozReview-Commit-ID: 5rD7YFij8v
d7fa5324198f: Bug 1435123 - HTMLEditor::GetBlock() has to specify given ancestor limit node to HTMLEditor::GetBlockNodeParent() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 29 Mar 2018 18:57:57 +0900 - rev 466854
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1435123 - HTMLEditor::GetBlock() has to specify given ancestor limit node to HTMLEditor::GetBlockNodeParent() r=m_kato This is a simple bug of internal API of HTMLEditor. HTMLEditor::GetBlock() tries to retrieve nearest ancestor block node (including itself) of a node. HTMLEditor::GetBlock() may have ancestor limiter typically it's active editing host to prevent to modify editing host or its ancestor accidentally. However, it forgets to call HTMLEditor::GetBlockNodeParent() with the given ancestor limit node. Therefore, if editing host is an inline element and its parent is a block element, the editing host is split accidentally. MozReview-Commit-ID: Ermmxdnk4KB
fb567fcd8ea9: Bug 1448780 - Get rid of nsIEditor.numberOfUndoItems and nsIEditor.numberOfRedoItems r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 26 Mar 2018 18:11:06 +0900 - rev 466098
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1448780 - Get rid of nsIEditor.numberOfUndoItems and nsIEditor.numberOfRedoItems r=m_kato nsIEditor.numberOfUndoItems and nsIEditor.numberOfRedoItems are shortcut property for nsITransactionManager.numberOfUndoItems and nsITransactionManager.numberOfRedoItems of the editor. However, anybody uses nsITransactionManager directly. So, we can get rid of them. MozReview-Commit-ID: 70J0bsxDNCC
d3a025d0c732: Bug 1447924 - part 7: Implement AddTransactionListener() and RemoveTransactionListener() in EditorBase and TransactionManager r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 23 Mar 2018 18:55:56 +0900 - rev 466091
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1447924 - part 7: Implement AddTransactionListener() and RemoveTransactionListener() in EditorBase and TransactionManager r=m_kato 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
f44840389420: Bug 1447924 - part 6: Implement EnableUndoRedo(), DisableUndoRedo() and ClearUndoRedo() in EditorBase and TransactionManager r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 23 Mar 2018 15:25:13 +0900 - rev 466090
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1447924 - part 6: Implement EnableUndoRedo(), DisableUndoRedo() and ClearUndoRedo() in EditorBase and TransactionManager r=m_kato 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
869a1445816b: Bug 1447924 - part 5: Merge TextEditor::Undo()/Redo() with EditorBase::Undo()/Redo() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 23 Mar 2018 01:21:17 +0900 - rev 466089
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1447924 - part 5: Merge TextEditor::Undo()/Redo() with EditorBase::Undo()/Redo() r=m_kato EditorBase::Undo() and EditorBase::Redo() implement only undo/redo function. TextEditor::Undo() and TextEditor::Redo() call them with calling some notification methods. However, this causes redundant AutoRules instance creation and doesn't make sense to separate them under current design. Therefore this patch merges them into TextEditor. Unfortunately, they are XPCOM methods but we cannot implement proper overloads of non-virtual since they are already minimized design. Fortunately, reducing only one virtual call per undo/redo isn't so effective. So, let's keep simpler design. Additionally, this patch makes them stop committing composition because Chrome does not commit composition even if "undo"/"redo" is requested with execCommand() during composition and it doesn't make sense to try to undo/redo after committing composition since first undoable transaction becomes the committing composition and committing composition causes removing all transactions from redo transaction queue. MozReview-Commit-ID: 78qlV2I9Lzk
08b900a07115: Bug 1447924 - part 4: Optimize NumbeOfUndoItems(), NumbeOfRedoItems(), CanUndo() and CanRedo() of EditorBase r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 23 Mar 2018 00:08:38 +0900 - rev 466088
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1447924 - part 4: Optimize NumbeOfUndoItems(), NumbeOfRedoItems(), CanUndo() and CanRedo() of EditorBase r=m_kato 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
362c6382d265: Bug 1447924 - part 3: Rename nsTransactionStack to mozilla::TransactionStack r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 22 Mar 2018 23:30:48 +0900 - rev 466087
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1447924 - part 3: Rename nsTransactionStack to mozilla::TransactionStack r=m_kato Then, all classes in editor/txmgr is now in mozilla namespace and all headers which are included by other directory are now exposed. So, we can remote local includes from other directories now. MozReview-Commit-ID: Kdb1c4Hp9Sy
c630f585884a: Bug 1447924 - part 2: Rename nsTransactionItem to mozilla::TransactionItem r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 22 Mar 2018 23:07:36 +0900 - rev 466086
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1447924 - part 2: Rename nsTransactionItem to mozilla::TransactionItem r=m_kato MozReview-Commit-ID: 5EmFPCaRYWm
08e82e58140d: Bug 1447924 - part 1: Rename nsTransactionManager to mozilla::TransactionManager r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 22 Mar 2018 22:15:54 +0900 - rev 466085
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1447924 - part 1: Rename nsTransactionManager to mozilla::TransactionManager r=m_kato We should rename nsTransactionManager to mozilla::TransactionManager before adding new non-virtual methods. MozReview-Commit-ID: JsivNVfDhex
d9d67351fd04: Bug 1448282 - TSFTextStore should append a pending action for dispatching keyboard event into the queue if OnUpdateComposition() is called without new range r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 26 Mar 2018 15:07:59 +0900 - rev 466084
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1448282 - TSFTextStore should append a pending action for dispatching keyboard event into the queue if OnUpdateComposition() is called without new range r=m_kato OnUpdateComposition() may be called without new range instance by some TIPs when they starts to modify composition string. At this timing, TSFTextStore should append a pending action for dispatching keyboard event into the queue. Without this patch, OnUpdateComposition() creates incomplete pending action for composition update and then, MaybeDispatchKeyboardEventAsProcessedByIME() appends pending action for dispatching keyboard event from another point immediately (e.g., from SetText()), then, finally, the caller of MaybeDispatchKeyboardEventAsProcessedByIME() appends another pending action for composition update with proper composition string. Therefore, the first pending action for composition update clears composition string before actually updating it with new composition string. In other words, new pending action for dispatching keyboard event splits a pending composition update. So, this patch prevents the splitting. MozReview-Commit-ID: 9pYO9pm3Vh9
e381311f2847: Bug 1447213 - Change editor methods which take |const EditorRawDOMPoint&| but called with EditorDOMPoint.AsRaw() to template methods r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 20 Mar 2018 14:05:47 +0900 - rev 465739
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1447213 - Change editor methods which take |const EditorRawDOMPoint&| but called with EditorDOMPoint.AsRaw() to template methods r=m_kato 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
2013763dd2b6: Bug 1423693 - Make IMContextWrapper::Init() resolve actual IM if active IM context ID is "xim" and there is XMODIFIERS env r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 19 Mar 2018 14:22:52 +0900 - rev 464994
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1423693 - Make IMContextWrapper::Init() resolve actual IM if active IM context ID is "xim" and there is XMODIFIERS env r=m_kato On some Linux environment, GTK_IM_MODULE env may be "xim". Then, actual IM is specified with XMODIFIERS env with "@im=". Therefore, if active IM context ID is xim, IMContextWrapper::Init() needs to look for actual IM name in XMODIFIERS. MozReview-Commit-ID: 1aGjBkF4AQn
2c6beffd290b: Bug 1445569 - part 4: Get rid of EditorBase::GetStartNodeAndOffset() and EditorBase::GetEndNodeAndOffset() r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 15 Mar 2018 21:25:41 +0900 - rev 464560
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1445569 - part 4: Get rid of EditorBase::GetStartNodeAndOffset() and EditorBase::GetEndNodeAndOffset() r=m_kato 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
d8ffb2c205d5: Bug 1445569 - part 3: Make TextEditRules::CheckBidiLevelForDeletion() take |const EditorRawDOMPoint&| instead of |nsINode*| and offset in it r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 15 Mar 2018 18:38:46 +0900 - rev 464559
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1445569 - part 3: Make TextEditRules::CheckBidiLevelForDeletion() take |const EditorRawDOMPoint&| instead of |nsINode*| and offset in it r=m_kato There are 2 callers of TextEditRules::CheckBidiLevelForDeletion(). One of them will start to use EditorRawDOMPoint. Therefore, making it take |const EditorRawDOMPoint&| instead of |nsINode*| and offset in it keeps the caller simpler. MozReview-Commit-ID: DRJXo8gnzba
78b6dcb16d04: Bug 1445569 - part 2: Make WSRunObject::PriorVisibleNode() and WSRunObject::NextVisibleNode() take |const Editor(Raw)DOMPoint&| instead of a pair of |nsINode*| and offset in it r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 15 Mar 2018 18:23:50 +0900 - rev 464558
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1445569 - part 2: Make WSRunObject::PriorVisibleNode() and WSRunObject::NextVisibleNode() take |const Editor(Raw)DOMPoint&| instead of a pair of |nsINode*| and offset in it r=m_kato Similar to the constructor of WSRunObject, PriorVisibleNode() and NextVisibleNode() callers may become ugly if the callers start to use Editor(Raw)DOMPoint. So, let's make them take Editor(Raw)DOMPoint instead of a pair of nsINode* and offset in it. Note that a lot of callers of them already use Editor(Raw)DOMPoint. So, we don't need to keep maintain overloads which takes nsINode* and offset in it directly. MozReview-Commit-ID: 3avMtL000nd
918ae45e7198: Bug 1445569 - part 1: Create WSRunObject constructor which takes |const Editor(Raw)DOMPoint&| instead of |nsINode*| and offset in it r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 15 Mar 2018 17:56:20 +0900 - rev 464557
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1445569 - part 1: Create WSRunObject constructor which takes |const Editor(Raw)DOMPoint&| instead of |nsINode*| and offset in it r=m_kato The following patches make some WSRunObject users use EditorRawDOMPoint or EditorDOMPoint instead of a pair of nsINode and offset in it. Then, the code becomes too long like: > WSRunObject object(mHTMLEditor, pointToDoSomething.GetContainer(), > pointToDoSomething.Offset()); This is ugly and not easier to read than: > WSRunObject object(mHTMLEditor, pointToDoSomething); So, we should create alternative constructor of WSRunObject first. MozReview-Commit-ID: GiNWRBLl7zB
6d25e14fec76: Bug 1445929 - Make Editor(Raw)DOMPoint::IsEndOfContainer() check if mParent is container node before checking mChild r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 15 Mar 2018 22:08:19 +0900 - rev 464556
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1445929 - Make Editor(Raw)DOMPoint::IsEndOfContainer() check if mParent is container node before checking mChild r=m_kato Editor(Raw)DOMPoint::IsEndOfContainer() checks mIsChildInitialized before referring mChild. However, it may be true even if mParent is not a container node like a text node. Therefore, if mParent is a text node and mIsChildInitialized is true, it always returns true (i.e., even if mOffset isn't same as length of mParent). This patch makes it check mParent->IsContainerNode() before checking mIsChildInitialized because after checking mIsChildInitialized, it validates the relation of the members. So, this keeps the validation simple. MozReview-Commit-ID: K2XrAZoNv2I
ce9c476f9dfc: Bug 1445935 - HTMLEditRules::SplitMailCites() remove left node of split node if it becomes empty r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 15 Mar 2018 22:34:57 +0900 - rev 464510
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1445935 - HTMLEditRules::SplitMailCites() remove left node of split node if it becomes empty r=m_kato Before bug 1413181, HTMLEditRules::SplitMailCites() receives left node of split node with |leftCite| from SplitNodeDeep(). However, the out argument was removed by the bug and now, it can be retrieved with SplitNodeResult::GetPreviousNode(). Its result is used for creating <br> element etc, but not set to |leftCite| but HTMLEditRules::SplitMailCites() still checks if |leftCite| is empty to remove it from the DOM tree. So, now, both |leftCite| and |rightCite| are not necessary and HTMLEditRules::SplitMailCites() should use |previousNodeOfSplitPoint| instead of |leftCite|. MozReview-Commit-ID: 408MJt6X1IV