nsRange::DoSetRange() adds/remove its root to/from mutation observer, initializes common ancestor, registers itself to the common ancestor, unregisters itself from old common ancestor, and notifies selection listeners of selection change.
However, those runtime cost is expensive but on the other hand, a lot of callers set both start and end of the range and that causes calling DoSetRange() twice.
This patch renames Set() to SetStartAndEnd() for easier to understand the meaning and make it call DoSetRange() only once.
MozReview-Commit-ID: FRV55tuBAgg
--HG--
extra : rebase_source : 67adf929cf119e2425f7d3741651217522094590
nsIDOMText is old interface and it needs QI to access node etc. So we should use Text etc.
MozReview-Commit-ID: 7VrTrE0p2Q9
--HG--
extra : rebase_source : baa6601708d4b71e624a4dc893cc413d7743dbeb
SplitStyleAbovePoint can return null for split node, but we don't check it.
Also, this crash occurs on paste operation, so I think that there is 100% reproduce test. But I cannot find it.
MozReview-Commit-ID: 69OlPTc0I9h
--HG--
extra : rebase_source : 61eea8af83e60cc4f9c6f25d2952d57d0fea1d05
When setting same value (including empty to empty), some browsers might not turn off undo. If settings non-empty value, all browsers doesn't turn off undo. Also, if empty value, Edge and Chrome doesn't turn off undo.
MozReview-Commit-ID: 1nVYEzBr5KJ
--HG--
extra : rebase_source : e49f38e7c5a8f69902d6320eb6740e34e3f161ed
Actually, input.value setter behaviour (when editor has focus) is the following.
- select all
- delete selection
- delete text node
- insert text
- create text node
- create nsIFrame since we don't support lazy construction for editable element
It is too expensive to change text. So I would like to change like the following when there is 1 text node only (normal case). If child nodes isn't 1 text node only, use original way.
- set text on existed text node
So, for this fast path, I would like to add SetText transaction API.
MozReview-Commit-ID: A7bjXtCtSoB
--HG--
extra : rebase_source : ff6348d7a3304e676a0a4b897f91623962961ae0
The MOZ_CRASH was added because we were lacking a implementation of ServoDeclarationBlock::GetPropertyValueByID, but it was added in Bug1294299
MozReview-Commit-ID: GPsFvTLxsMd
--HG--
extra : rebase_source : d51837def3a9a76dfa2af01dcb26b607dd48a5e6
Currently, edit commands for native key bindings are stored in widget. This is
stateful and really complicated in content process because it needs to cache
them.
We can make this simpler if we make WidgetKeyboardEvent store edit commands for
the key combination. Then, child process can handle it even if it's delayed
event or it's a nested event.
This patch adds arrays to WidgetKeyboardEvent to store edit commands which are
initialized with nsIWidget::ExecuteNativeKeyBinding() and adds
WidgetKeyboardEvent::ExecuteEditCommands() to execute stored edit commands as
same as nsIWidget::ExecutenativeKeyBinding().
MozReview-Commit-ID: BGRvBrLz5lp
--HG--
extra : rebase_source : b7ecd704d9c331ca1e0aedc66f230114015b853b
InitSpellChecker allows that 3rd callback parameter is null. We should consider that it is null.
MozReview-Commit-ID: BMAM6BiYlw5
--HG--
extra : rebase_source : fbe767694d6380988854ff133b780b8fe334bf3a
nsIEditRules::GetDocumentIsEmpty doesn't return error without null parameter, so we should use bool as return value instead.
MozReview-Commit-ID: HIoQmKu6ETF
--HG--
extra : rebase_source : 570452e7072d8e0e837bb2822c9c0ab9c0d1a8cf
Nobody uses them anymore. Therefore, we can remove them from the tree.
MozReview-Commit-ID: KTqCeI2eeFW
--HG--
extra : rebase_source : f3fc274f39c135af51245efd4c4aebbc4c49a61f
IMEStateManager should cache nsIWidget for sPresContext at caching sPresContext. Then, even if sPresContext has gone, IMEStateManager can clean up with the nsIWidget cache.
Unfortunately, editor has some bugs about calling IMEStateManager::UpdateIMEState(). That is, calling it *before* IMEStateManager::OnFocusChange(). In such case, this patch makes UpdateIMEState() ignore the call.
MozReview-Commit-ID: 1cydI03WyB8
nsIDocumentEncoder has nativeInit for nsIDocumnet, we should use it to reduce QueryInterface.
MozReview-Commit-ID: Ffn19yf9jra
--HG--
extra : rebase_source : 37c8b27cc0eddd4f0501ec1e61ea27d74ee1e6f3
From profiling TextEditor::OutputToString, most of WillOutputText is ToLowerCase. So, we should use LowerCaseEqualsLiteral instead. It can reduce string copy.
MozReview-Commit-ID: LwqZtxIJTbW
--HG--
extra : rebase_source : 94da785d8288dfd93666a3dcb2d374874c79db89
To clean up TextEditRules, I would like to replace nsIDOMNode with nsINode and nsIContent in TextEditRules.
GetTopEnclosingPre is unused define, so I also remove it.
MozReview-Commit-ID: 6LraexH5t4m
--HG--
extra : rebase_source : 1037dcfd949d544282dc30360bd43773f21fd929
It's not only inefficient, but also prone to buggyness. Since styles may not be
up-to-date when it happens.
Post a reconstruct instead, which ensures a style flush happens before running
frame construction.
MozReview-Commit-ID: DrakHsJv5fY
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
--HG--
extra : rebase_source : 11900af908654336cc2391ab9480542c5474e38f
On Ubuntu 16.04 TLS, test_dragdrop.html due to control margin. So we should adjust the point of dragstart.
MozReview-Commit-ID: EPW2UnaIWRt
--HG--
extra : rebase_source : a97c66dc36328563497130aa7a3829bc8a9eb204
This test is failing intermittently even on non-QuantumRender builds, and bug
1361820 is tracking that issue. Once that is fixed we should be able to re-enable
this test.
MozReview-Commit-ID: HANsz08bujB
--HG--
extra : rebase_source : 4500022a5ffbac6bbd4de3e61c3dc3bba3881b1f
We can't depend on information from layout to be correct unless we've
flushed pending notifications, which we can't do at every editability
check. So let's forget about layout. Nobody knows why editability ever
depended on visibility in the first place.
This allows us to revert the additions from bug 795418 as well.
The original test-case submitted on the bug report was very big and
complicated, so I have a minimal test-case instead. This might not
exactly correspond to the originally reported bug, but this fix works for
both the original and minimal test case.
MozReview-Commit-ID: LOKjlgiAEOT
--HG--
extra : rebase_source : 5aaeae87fdc0dd78cb6f1060399c09d2945f8e08
Now that this is a pref that is different in different versions, tests
have to work no matter what the pref's value is. For tests that
actually tested line-breaking-related behavior, I made them test all
three separator values. For tests that tested something else and only
incidentally depend on the default paragraph separator, I set
defaultParagraphSeparator to "div".
MozReview-Commit-ID: 8m7eoFRXpEy
--HG--
extra : rebase_source : dc664e87f7ce4f621aa48639cef6e754793e8ab4
This is regression-prone, so dev.platform discussion concluded we want
it behind a pref. We might turn the pref off for beta and/or release
for now as well.
MozReview-Commit-ID: 2H2et3RElZx
--HG--
extra : rebase_source : baf7e679ca1ee16016666d7697990c4f64ecf83e
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
When CanSpellCheck isn't called yet, mSpellChecker won't be initialized. So we should check it before running DictionaryFetcher.
I think that UpdateCurrentDictionary is called by OnFocus as long as nsEditorSpellCheck::InitSpellChecker isn't called. But I cannot find test case to reproduce this...
MozReview-Commit-ID: 5H1pJ0AnX5X
--HG--
extra : rebase_source : 5f2a59261c67a7f8f363588c7596e68f6debff9e
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
Now, mozInlineSpellChecker::UpdateCurrentDictionary will use sync IPC messages via nsEditorSpellCheck::DictionaryFetched.
Part 1 adds async API to set current dictionary. So we should use it on nsEditorSpellCheck::DictionaryFetched instead of sync API.
MozReview-Commit-ID: 5gl2eQpzKm1
--HG--
extra : rebase_source : 1fabc4abdd170494f1804ad875a181e652ea66a0
Now, mozInlineSpellChecker::UpdateCurrentDictionary uses several sync IPC message to update spellcheck dictionary. So I want async IPC to set dictionary.
Also, since nsEditorSpellCheck::DictionaryFetched calls SetCurrentDictionary several times (max: 6 times), so to reduce calls, we should use list of dictionary.
MozReview-Commit-ID: EVMAJxpMT2X
--HG--
extra : rebase_source : 5a1ed28bd6eb1dd9d3a6a634a286531b7ebb32c7
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
AsyncSpellCheckTestHelper.jsm uses on mochitest and reftest, so we shouldn't ship it in release package
MozReview-Commit-ID: CT8f8DRVwb
--HG--
extra : rebase_source : 4cd803fed4f9215f5237996c83128f5434aaad88
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
AsyncSpellCheckTestHelper.jsm uses on mochitest and reftest, so we shouldn't ship it in release package
MozReview-Commit-ID: CT8f8DRVwb
--HG--
extra : rebase_source : fec37ae258f7c0d8ff76143da79ca182b66f0a52
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
In cases, where the caller is looking for the locale to be used for JS Intl API,
we can now replace it with `undefined` which causes JS Intl API to use the default
locale which since bug 1346674 is resolved to the app locale.
This allows us to remove a lot of calls for the app locale.
The remaining ones are split between `AsBCP47` and `AsLangTag`.
Here, the `AsLangTag` is used, as described in the API docs, for cases where
the language string is used for localization purposes, such as language negotaition
matching to our language resources etc.
`AsBCP47` is used when the returned value is handed over to ICU API.
MozReview-Commit-ID: DzmFEUvMq3N
--HG--
extra : rebase_source : 513ed31d995864939aa893e73c81ffdf591a6617
In cases, where the caller is looking for the locale to be used for JS Intl API,
we can now replace it with `undefined` which causes JS Intl API to use the default
locale which since bug 1346674 is resolved to the app locale.
This allows us to remove a lot of calls for the app locale.
The remaining ones are split between `AsBCP47` and `AsLangTag`.
Here, the `AsLangTag` is used, as described in the API docs, for cases where
the language string is used for localization purposes, such as language negotaition
matching to our language resources etc.
`AsBCP47` is used when the returned value is handed over to ICU API.
MozReview-Commit-ID: DzmFEUvMq3N
--HG--
extra : rebase_source : 13fa4c397ba4c79303a2cd76684b5b8c4bd17331
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
Masayuki Nakano
Makoto Kato
Fernando Jimenez Moreno
Shing Lyu
sjh21a
Mats Palmgren
Carsten "Tomcat" Book
Wes Kocher
Ryan VanderMeulen
Sebastian Hengst
Lee Salzman
Bas Schouten
Milan Sreckovic
Matt Brubeck
Yoshi Huang
Christoph Kerschbaumer
Emilio Cobos Álvarez
Kartikaya Gupta
Aryeh Gregor
Manish Goregaokar
Iris Hsiao
Florian Queze
Xidorn Quan
Dan Banner
Brian Birtles
Phil Ringnalda
Olli Pettay
Mason Chang
Zibi Braniecki
Boris Zbarsky
David Major
Joel Maher
Andreas Farre
Michael Layzell
aceman
Masatoshi Kimura
Andrea Marchesini
Cameron McCormack