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
