We have a possible loop like this bug. So we should use stack class for loop.
MozReview-Commit-ID: LQb9w8LEtbx
--HG--
extra : rebase_source : 67c40a0f2e3528d58fe7d0ea6ca290bbc136c6d1
This crash occurs that range is nullptr.
DeleteNonTableElements will update selection and range, so we shouldn't use range count before modifying selection. So we should save range data for loop.
MozReview-Commit-ID: C9c4TZqRvUc
--HG--
extra : rebase_source : cbadc6d6d82e1c904c20309f2e82f2b6c2f438e7
Although this crash doesn't occur after landing bug 1369140, we should add this test to crashtest.
MozReview-Commit-ID: mRm4P876zg
--HG--
extra : rebase_source : 9a85c8ba3a5652000512d165b82df9aa2c8176e1
TextEditor::OutputToString() uses DocumentEncoder if TextEditRules::WillOutputText() doesn't handle it. However, TextEditRules::WillOutputText() doesn't handle it even if it's really simple case of <input type="text"> and <textarea>.
This patch makes TextEditRules::WillOutputText() handle it if DOM tree in the editor root element is expected and there is no special flag which requires complicated handling.
MozReview-Commit-ID: 3HvdTAWRpw0
--HG--
extra : rebase_source : ab3e630faa95ce8d4c1e9eb1786b7ece7212e38f
mozilla::EditorBase stores nsISelectionController and nsIDocument with nsWeakPtr. However, nsWeakPtr requires QI to retrieve actual pointer and it makes some damage to the performance. If mozilla::WeakPter were available for them, it'd be great. However, it's not available with nsISelectionController nor nsIDocument because it's possible to implement SupportsWeakPtr only with their subclasses but the subclasses shouldn't be referred by editor. Therefore, this patch creates mozilla::CachedWeakPtr<class T> which stores both raw pointer (as cache) and nsWeakPtr and when its cache is requested, it checks if the object referred by nsWeakPtr is still alive.
Additionally, this patch hides the members from subclasses of EditorBase for reducing the maintenance cost.
MozReview-Commit-ID: FvtM7453Vv8
--HG--
extra : rebase_source : a524a8ea327c3993645fafa81db8aef65090f1e0
EditorBase stores PlaceholderTransaction with nsWeakPtr. However, retrieving its pointer requires a QI. So, for reducing the QI cost, EditorBase should use WeakPtr instead and PlaceholderTransaction needs to inherit SupportsWeakPtr instead of nsSupportsWeakReference.
MozReview-Commit-ID: IYwSTbJebMk
--HG--
extra : rebase_source : fa728b09afa826506befbeb46aba54075ecf4787
Since RangeUpdater::SelAdj* method of nsIDOM* version requires additional QI and we don't use nsIDOM* as parameter, it is unnecessary to keep it.
MozReview-Commit-ID: 4XyYBG6Qrhl
--HG--
extra : rebase_source : 5fd830a2ffeff944471f026ded704a46ac4dd3d5
TextEditor::UpdateIMEComposition() uses AutoPlaceHolderBatch class which calls NotifyEditorObservers(eNotifyEditorObserversOfBefore) automatically when it's created. Therefore, it causes calling NotifyEditorObservers(eNotifyEditorObserversOfBefore) twice from TextEditor::UpdateIMEComposition().
MozReview-Commit-ID: DJqzmCtyHCf
--HG--
extra : rebase_source : 44e350d66a01ba9e0beaada0f349422a896acf3d
Since this step requires keyboard operation, we cannot create web-platform-test.
MozReview-Commit-ID: ExuaNOj9JG4
--HG--
extra : rebase_source : 0115e48fe1c3bdd7495e3bfc610f03ac1ee15ecb
GetNodesForOperation(..., makeBasicBlock) will get all nodes of promoted range. But it includes invisible text node after <br> element. So HTMLEditRules::MakeBasicBlock will creates block for invisible text node.
So we should remove invisible text node from nodes of formatBlock.
MozReview-Commit-ID: L1bsPAYcwx3
--HG--
extra : rebase_source : d9e4e3ff3eef41fb7a4b4c88d73d000b2e53806f
This avoids dynamic allocations in SelectionState::SaveSelection() in the common
case for the selections that only have a maximum of one range stored in them.
Disable 461917-1.xhtml under dom/xul/crashtests/ because I cannot reproduce
it locally.
Annotate assert-if on some crashtests (bug 1370830). Other modifications are
all removal of fails-if.
MozReview-Commit-ID: 6Q2A5M5rOry
--HG--
extra : rebase_source : b282a919fcda6287fe2eaa6b139a11f2663ad578
GetSelectionController is virtual method, but we should have non-virtual version of GetSelectionController that return value is nsISelectionController since we have a lot of call of GetSelection().
MozReview-Commit-ID: 41JFqTyIh0b
--HG--
extra : rebase_source : 4d40d1a8b31c2b6aff3f3b9ff4609bb3e41ea8f6
Editor still uses CollapseNative and ExtendNative even if it uses Selection, not nsISelection. CollapseNative and ExtendNative are virtual method, but Selection::Collapse and Extend are non-virtual. So, we should use Selection::Collapse and Extend instead.
MozReview-Commit-ID: 1AEaaJRbkIm
--HG--
extra : rebase_source : 33b4059c558cfb88c61cedc4e71de8263f2fc387
textarea element will use fallback code (using TextEditor::DeleteSelection) to set empty value for SetText.
Actually, if EditorBase::HandleInlineSpellCheck returns error in AfterEdit, we might not create bogus node and trailing br node. Since SetText's fallback uses DeleteSelection, SpellCheckAfterEditorChange will return error when previous selection is invalid on SetText transaction.
mozInineSpellChecker::SpellCheckAfterEditorChange creates the range between previousSelection and anchorNode. So when using setText, we should set the range of all text, and we should not use previous selection for SpellCheckAfterEditorChange.
MozReview-Commit-ID: 7eDzMdRmOSz
--HG--
extra : rebase_source : 67861ca3c779b2fb6b5a26174f391fa7fb9ca390
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
Makoto Kato
Masayuki Nakano
Wes Kocher
Carsten "Tomcat" Book
Olli Pettay
Ehsan Akhgari
Bill McCloskey
Henri Sivonen
Ting-Yu Lin
Brad Werth
Fernando Jimenez Moreno
Shing Lyu
sjh21a
Mats Palmgren
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