When defaultParagraphSeparator is not "br", and we hit Enter on a line
that is not contained in any block element, we first create a new <div>
(or <p>) wrapper to hold the line's contents. If creating this wrapper
fails for some reason, we go ahead and insert a <br> instead.
In some cases, we would get confused and think we didn't create the
block element when really we did. We would insert a <br>, and
afterwards something would get rid of the empty block element. In a
corner case where the line only consisted of a <br> to start with, this
would result in nothing happening, because the original <br> was removed
when creating the block element, and only one <br> was inserted to
replace it.
The correct fix is to just not get confused!
MozReview-Commit-ID: 1U8KHC71bfw
--HG--
extra : rebase_source : 50640615a3a652c3a74c1aef5412eb82daf8c5fb
All editor code gets nsIDocumentEncoder from TextEditor::GetAndInitDocEncoder(), so we can have a cache into TextEditor, then return cached object.
MozReview-Commit-ID: IEoOvz7BG7T
--HG--
extra : rebase_source : 1b30325c99fbc43dc77453325e97e88b439285e2
ConfirmSelectionInBody uses a lot of QI and TextEditUtils::IsBody call to check body element. So we shouldn't use nsIDOM* to avoid QI and EditorBase::GetTag().
Also, if did not found body element, it calls collapse to set caret. If collapse is successful, we might not have to check end selection... How do you think?
MozReview-Commit-ID: F7FhPrlEpCc
--HG--
extra : rebase_source : 85b5c99be0085dd579a9b650207c876cd17a2410
Since Part 2 improves foucs performance, these tests will be failed because spellchecker works later. So using UpdateCurrentDictionary, dictionary is updated before test.
MozReview-Commit-ID: 69aC1rQd4LY
--HG--
extra : rebase_source : 50e0449b727352ff2f8e2a08605cc3f9d933d6d9
Such as <input type=password>, focused element doesn't use spellchecker, we should not call UpdateCurrentDictionary. Also, when the attribute is changed, we should call UpdateCurrentDictionary if uninitialized.
MozReview-Commit-ID: LSfDTAszviE
--HG--
extra : rebase_source : a3fe944099c625b7f525d33eae06a7b8e8992729
In the next patch we want to add a method called
GetUnanimatedStyleContextForElementNoFlush but that's much too long. Instead it
seems better to just drop 'ForElement' from all these methods since it should be
fairly obvious we are getting the style context for an element given that the
first argument is an element.
MozReview-Commit-ID: JQKaEuCKV2F
--HG--
extra : rebase_source : 3ba51f3b00d1ec7bc91102629d9c0abb88992fef
This matches Blink/WebKit, and is more similar to Edge than before, but
may cause compat problems for Gecko-only code or code paths. Sites can
revert to old behavior with:
document.execCommand("defaultparagraphseparator", false, "br").
This regresses test_bug430392.html on one test ("adding returns") and I
don't know why. The test involves embedded non-editable content and we
already have a lot of todos in that file, so I think it's tolerable.
MozReview-Commit-ID: Dml0bXxgu87
*aHandled was previously always set to true in WillMakeBasicBlock, which
was probably a bug but is not addressed in this commit.
MozReview-Commit-ID: 41JSmptVc0l
Before this change, if you did formatBlock on "a<span
contenteditable=false>b</span>c", it would become "acb", because the "a"
and "c" would be moved to the front of the node, and the "b" would be
left alone at the end because the editing code doesn't want to move it.
Now we will move the "b" as well, even though it's not editable, so that
the node remains "abc". The rule is that a non-editable element cannot
have its attributes or children changed, but it can have its parent
changed, so there's nothing wrong with moving it here.
On the way, I fixed an exception in insert*List if there was an
uneditable inline node around. I don't intend to fix all the todo's in
the test, but now it should have better coverage, at least.
MozReview-Commit-ID: 3okcGq4an3f
I don't personally agree with this behavior (although I did spec it some
years ago), but it's the behavior of all other UAs, so we should do it
anyway.
MozReview-Commit-ID: IiIg41kMJIU
This is what test_htmleditor_keyevent_handling.html expects. It
historically made no difference in the case tested there, because we
inserted a <br> either way, but now it will make a difference. I don't
know what an HTML editor in plaintext mode even means, so I don't know
if this change is actually the intended behavior.
MozReview-Commit-ID: 64w6bb9Q1pD
Behavior per spec and Chrome is to just delete the selection. We
already do this for insertHTML.
MozReview-Commit-ID: AWZhH6lIwuO
--HG--
extra : rebase_source : 353c3b628eb6a609de121e25bb7a11e579d29400
TESTING_JS_MODULES uses testing-common, not gre. So we should replace gre with testing-common for mochitest.
MozReview-Commit-ID: BqsS2D3IGR6
--HG--
extra : rebase_source : a8553684f8f106c1dfb6e2d9b51df7ebeb15275d
CLOSED TREE
Backed out changeset 941e0f9ff9a7 (bug 1351074)
Backed out changeset 4fdf3b87a70b (bug 1351074)
Backed out changeset 586428f69838 (bug 1351074)
TESTING_JS_MODULES uses testing-common, not gre. So we should replace gre with testing-common for mochitest.
MozReview-Commit-ID: BqsS2D3IGR6
--HG--
extra : rebase_source : 2143fcdf33c428c82c6b2e00b542649b958aeccc
m-c, c-c, addons and bluegriffon don't use this interface, so we can remove it.
MozReview-Commit-ID: I8sVLpDR2gx
--HG--
extra : rebase_source : f88633271bf61ccc55098593fedff0dd7a561f21
At first, HTMLEditor::GetActiveEditingHost might return null in this situation, we should check whether nullptr is returned. At second, SplitNodeDeep returns error since curent is design mode and selection node has no parent. So we should check error.
MozReview-Commit-ID: 2YlWXPNtf80
--HG--
extra : rebase_source : 5e9752353cdf8db906e94391e9660f61336a9614
This is a kind of regression of bug 1088054 part 6. If new block doesn't have child node, GetLastEditableChild will return null after landing bug 1088054. So, we should use new block when GetLastEditableChild returns null.
MozReview-Commit-ID: Gzt1Xp3Sl47
***
P1
MozReview-Commit-ID: 8LVp5qGnme4
--HG--
extra : rebase_source : f0ed76b65517168b6b11edf96164b3e596038fc1
Edit transactions should store their editor instance with strong reference and they should be released at destroying the editor.
MozReview-Commit-ID: D67KU8WFxyo
--HG--
extra : rebase_source : 28c8a37498cad9f2e308eb4416cef76cf395bb9c
There are no app which replaces transaction manager of editor. Additionally, replacing transaction manager of an editor with different editor or same editor but after initialized again due to some reasons may cause unexpected problems.
Therefore, this patch makes it readonly.
MozReview-Commit-ID: K7zepOjrzvC
--HG--
extra : rebase_source : ee1944af57c8102628b8cffbc720d2b8e5e9088d
I want to remove nsIDOMNodeList usages from editor excepting old debug code.
(BTW, we might have to change to <meta charset> instead of <meta http-equive>, but it should handle by another issue)
MozReview-Commit-ID: ArAVOHigKNW
--HG--
extra : rebase_source : 74ddcaa760c0cc80d6395acb3a6c9374a80dec25
extra : histedit_source : f582131f2b1d5cca8b024b0936ad04634566014e%2Ce95119c3c80903588b24fc66cd6a5b3a8e1458a9
EditorBase::CreateTxnForDeleteInsertionPoint() appends DeleteTextTransaction or DeleteNodeTransaction to the given EditAggregateTransaction. For consistency with other CreateTxnFor*() methods, this should just create a transaction and return it. Then, the caller should append the transaction to EditAggregateTransaction.
MozReview-Commit-ID: 6sqEijicFHE
--HG--
extra : rebase_source : 1443b3d9c8e90044994ad87965a26d76926e2c72
After bug 769967, FindUserSelectAllNode always returns nullptr. So we get rid of this method. Also, AreaRestriction is used by this, so it is unnecessary now.
MozReview-Commit-ID: HTc8PUCQmy5
--HG--
extra : rebase_source : 11b19a1976f6696e0d872c9020b90701dd22c8c0
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
Selection may be changed by methods of Selection or methods of Range retrieved by Selection.getRangeAt(). Selection::NotifySelectionListeners() is called after every selection change of each of them, so, this method must be a good point to move focus.
If new common ancestor of all ranges is editable and in an editing host, we should move focus to it. Otherwise, if an editing host has focus but new common ancestor is not editable, we should move focus from the editing host.
For consistency with the other browsers, this patch doesn't move focus to other focusable element.
MozReview-Commit-ID: 6sNsuzwqECX
--HG--
extra : rebase_source : 9ba52ab0bd1249abded81019847c85182ca1926e
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
Similar to DeleteNodeTransaction, DeleteRangeTransaction should take all necessary information as its arguments. However, different from DeleteNodeTransaction, this doesn't need to implement CanDoIt() since nobody checks the state.
MozReview-Commit-ID: 2Z9fNtGeJ9c
--HG--
extra : rebase_source : fe3f75126a8975a0edb00a6c0709134b0a0f4d87
I'd like to make mNodeToDelete an owning-non-null member, but it's not cycle collector aware. Therefore, this patch only changes mEditorBase from pointer to reference.
MozReview-Commit-ID: H3wxmN1t92s
--HG--
extra : rebase_source : ca9984b47c9d242f82e395773a9a7f534e60c022
EditorEventListener listens any trusted focus/blur events which may be synthesized by JS without proper event class. Then, editor will setup selection limitation. This may cause odd behavior. Therefore, EditorEventListener should stop handling focus/blur events which do not come from nsFocusManager.
MozReview-Commit-ID: 7SlfIRgArkr
--HG--
extra : rebase_source : ade7009f1b87fbc629de32b6f22a85c87c72107f
Before I will fix some justify* command's bug, I would like to clean up HTMLEditRules::RemoveAlignment to get rid of nsIDOM* into this method.
MozReview-Commit-ID: 4UATycS5iBl
--HG--
extra : rebase_source : 7079a774b4b8359aeffbdbdf2efe0b45bd92c173
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
When selected nodes are <span style="font-weight: normal;">A</span>, toggle bold inserts new span element into parent node like <span style="font-weight: bold;"><span style="font-weight: normal;">A</span><span>. So bold isn't applied correctly.
IsCSSEquivalentToHTMLInlineStyleSet might return false even if style is applied. Because it returns true that style isn't default value. Since "font-weight: normal" is default property, it isn't removed.
So when style is already applied even if it is default value, we should remove it.
MozReview-Commit-ID: LgImkHRp9Ff
--HG--
extra : rebase_source : dd4d894495754a81abaf5a2aede1132056920beb
extra : histedit_source : 72d196cd9f90296eb00b97c1538704c714cc871c
Editor may need to create some new transaction during handling a mousedown event. Therefore, editor needs to finish pending composition transaction. So, mousedown event handler should commit composition first.
MozReview-Commit-ID: 2BaoYwB7wLS
--HG--
extra : rebase_source : 1babc2fd37ff08a1316a62943adc2a7a36d8ca53
RemoveEmptyNodes doesn't check whether parent node is null. So we shouldn't add null to skip list.
Also, although this crash depends on clang, if debug build, it will hit the assertion on all compiler.
MozReview-Commit-ID: GgiczVExlIn
--HG--
extra : rebase_source : 5ec0119a80d86dfeac5e970cdf540997cca24c34
Additionally, this patch removes unnecessary name space wrapper of IsCtrlShiftPressed(). Perhaps, it was necessary when mozilla::EditorEventListener was nsEditorEventListener.
MozReview-Commit-ID: EHzt7aRtYgQ
--HG--
extra : rebase_source : d38d73226de8f5563ad66de10f8f8ed701d766a1
Currently, we use alias NS_VK_* for WidgetKeyboardEvent::mKeyCode. Similarly, we should create alias enum for nsIDOMKeyEvent::DOM_KEY_LOCATION_*. Then, we can reduce the length and avoid to include nsIDOMKeyEvent in some cpp files.
MozReview-Commit-ID: 5cs4zQ061Lc
--HG--
extra : rebase_source : e6a6edd27718b9e3d4a40b07902d029791876999
HTMLEditRules can access both mTextEditor and mHTMLEditor, but we should use mHTMLEditor only on HTMLEditRules for readability.
MozReview-Commit-ID: HfzwAD554XQ
--HG--
extra : rebase_source : 7d722915a41eb878e2cd2ff711ac4925bd91d1d8
Items in mActionListeners may be removed during a call of a method of another item. Therefore, all items should be copied to different array before each loop referring mActionListeners.
MozReview-Commit-ID: FA2xXdJ9SoR
--HG--
extra : rebase_source : 054a58f5a82df6911d42b17fdb3f11738ceab2af
GetIsDocumentEditable is implemnted in EditorBase, TextEditor, and HTMLEditor. This is virtual method, we won't use EditorBase::GetIsDocumentEditable. Also, TextEditor::GetIsDocumentEditable and HTMLEditor::GetIsDocumentEditable are same implementation. So we should merge this to EditorBase.
MozReview-Commit-ID: 62euqUaYAuY
--HG--
extra : rebase_source : 1a3025aeddc61d0ae3e0de334472ee8393893114
So, EditorEventListener should grab mEditorBase in smaller scope as far as possible. And each event listener method shouldn't access mEditorBase directly at calling its method since it might be changed to another instance.
MozReview-Commit-ID: IUCl5gbh4ut
--HG--
extra : rebase_source : 217d881923193a25db0649fc1f1a87bd43fa4d99
EditorEventListener doesn't check if mEditorBase is available even after it's removed from the editor. If it becomes nullptr, i.e., it's detached from editor, it shouldn't continue to handle event.
This patch changes some methods' nsIDOM*Event argument to WidgetEvent since it's simpler.
MozReview-Commit-ID: CI3U4pfVxtb
--HG--
extra : rebase_source : 7135c4615f6a1dd8bb4b6698261c75a9f8c70930
Before cleaning up EditorEventListener, we need to make it use Widget*Event at each event method.
MozReview-Commit-ID: 482HHN0bCVV
--HG--
extra : rebase_source : a2f504ca931ec98945f7317b972b21d765304c92
Part 3 fix of bug 1310912 is incorrect for not composition transaction. PlaceholderTransation is for saving and restoring current selection for undo. So we shouldn't use range updater to normal transaction.
Composition transaction can modify multiple nodes and it merges text node for ime into single text node. So if current selection is into IME text node, it might be failed to restore selection by UndoTransaction. So we need update selection by range updater to work UndoTransaction.
Also, CompositionTransaction::UndoTransaction will set selection after committed text. So at finally, selection will set correct position that composition transaction wants.
MozReview-Commit-ID: 1NcH32YoKPQ
--HG--
extra : rebase_source : 8a29ef3d4d4c64997416a8f3c7fd174766764ad3
EditorEventListener::MouseDown() may be called by HTMLEditorEventListener::MouseDown() too. In this case, mEditorBase may be nullptr. Therefore, EditorEventListener::MouseDown() should check if mEditorBase is still available before using it.
MozReview-Commit-ID: 1wAgPdt3db0
--HG--
extra : rebase_source : aa06dce861d93728c4302986fbea6096192460d9
IMEStateManager::OnClickInEditor() may cause anything because it may set input context. For example, it may cause opening VKB, changing focus or reflow. So, mEditorBase here might have been gone.
MozReview-Commit-ID: C0SVzb5SueS
--HG--
extra : rebase_source : a09c214ca3e9f15024060b208fa0161a458464a0
Except to nsIEditorStyleSheets and nsITableEditor, we use NS_DECL macro into HTMLEditor, so we should use macro for both.
MozReview-Commit-ID: I6v9mRXNci6
--HG--
extra : rebase_source : bf71cce0ca293a16ac437ba52871d8b926c715a5
Both methods don't override by TextEditor and HTMLEditor. It is unnecessary to use as virtual method.
MozReview-Commit-ID: 6FNO78RauML
--HG--
extra : rebase_source : fb74a9b83a889ab2be04529527704f6de4b666dd
Both methods don't override by HTMLEditor. It is unnecessary to use as virtual method.
MozReview-Commit-ID: CKqb0bxKEOr
--HG--
extra : rebase_source : 3a2127618693c339ad38995936acc0a3332b5f2e
We don't have no overload method for both methods. So we shouldn't use virtual.
And, other transaction methods return transaction object directly, we should change to it.
MozReview-Commit-ID: 7CXz4XeOobk
--HG--
extra : rebase_source : e208484decec42496e88bbee5ed7d19b1f6daf91
extra : amend_source : 1ebe4378f6c8133b874e573c10c368ae96a51d45
Other transaction classes use EditorBase directly, but these transaction classes use nsIEditor. To remove nsIDOMDocument XPCOM interface usage, I would like to use EditorBase directly.
MozReview-Commit-ID: 3alRd9Zj5aZ
--HG--
extra : rebase_source : ed8e917201a7b8b84551aa8494b7879202553238
TextEditor::InsertBR is called from HTMLEditor::TypedText only. So we should move it to HTMLEditor.
MozReview-Commit-ID: 4rPcayd9T5n
--HG--
extra : rebase_source : 975bb799b7cb71a55e45c5f4169d3e30a9aa5a27
Some uses nsIDOMCharacterData to get the attribute of text node. But, by using Text object, we don't need nsIDOMCharacter. So we should use Text object instead of nsIDOMCharacterData instead if possible.
MozReview-Commit-ID: 1cwTUcecFj3
--HG--
extra : rebase_source : 2b3745c1aa71ccaca7def3d10e9ad655b4987991
Aryeh Gregor
Makoto Kato
Florian Queze
Sebastian Hengst
Dan Banner
Brian Birtles
Wes Kocher
Phil Ringnalda
Olli Pettay
Boris Zbarsky
Carsten "Tomcat" Book
Masayuki Nakano
Mats Palmgren
Iris Hsiao
David Major
Andreas Farre
Michael Layzell
aceman
Masatoshi Kimura
Andrea Marchesini
Cameron McCormack
Jorg K
William Chen