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
Makoto Kato
Wes Kocher
Milan Sreckovic
Masayuki Nakano
Shing Lyu
Christoph Kerschbaumer
Emilio Cobos Álvarez
Kartikaya Gupta
Aryeh Gregor
Manish Goregaokar
Carsten "Tomcat" Book
Iris Hsiao
Florian Queze
Sebastian Hengst
Xidorn Quan
Dan Banner
Brian Birtles
Phil Ringnalda
Olli Pettay
Mason Chang
Mats Palmgren
Matt Brubeck
Zibi Braniecki
Boris Zbarsky
David Major
Joel Maher