nsIHTMLEditor has several scriptable methods (addDefaultProperty(),
removeDefaultProperty(), etc.) that have nsIAtom parameters. We're in the
process of deCOMtaminating nsIAtom (bug 1392883) so these methods need to be
changed.
This patch does the following.
- It changes those methods to take an AString instead of an nsIAtom.
- For each existing method, it adds to HTMLEditor a new C++ method of the same
name that takes an nsIAtom parameter.
- It updates TextEditorTest.cpp to use strings instead of atoms, in order to
keep using the XPIDL methods.
- It updates test_bug1140105.html to pass strings instead of atoms to
getInlineProperty(). This removes the use of nsIAtomService.
--HG--
extra : rebase_source : e005c3b5a08207b3d5d5fb55c47c8bc475b33453
Since we enable lazy frame construction for editable region, whitespace only node might not have frame even if editable. This test has whitespace only node into contenteditable, we need adjust caret operation for this test.
MozReview-Commit-ID: GQfKiYdYOdi
--HG--
extra : rebase_source : 0685d724f6af050d79c1cf007c7ee48c05da14ac
test_bug655636.html refers gBrowser, however, it's available only in chrome
process and it's referred only for listening to "pageshow" event instead of
"load" event of the data URI. So, we must be able to use "unload" event of the
previous URL instead.
Although, this testcase (even without this change) won't cause crash even if
backing out the patch for bug 635636 anymore.
MozReview-Commit-ID: B8qOwVZqZQm
--HG--
extra : rebase_source : d383181886152684a8bf9c2caf7248d5f7582c0a
This test is turned off by bug 1269209 on e10s. But there is no exactly reason why this test on e10s is turned off.
Although I run this test on e10s now, it seems to pass this. So we should turn on this test even if e10s.
MozReview-Commit-ID: JHQP2ZYvsHL
--HG--
extra : rebase_source : 2bc45f0d2b5cc99bad93267f40191866264af414
This matches the spec and Chrome, and seems to bring us closer to Edge
and WebKit as well. It also matches our own behavior for addRange(),
which was changed in bug 1341137.
For collapse and selectAllChildren, we match the tests and browsers, but
the spec is incorrect at the time of this writing:
https://github.com/w3c/selection-api/pull/86
The removeAllRanges test hadn't been updated for the spec change.
MozReview-Commit-ID: DTK8283k5IP
--HG--
extra : rebase_source : 54701e7136c33ebce651d5f74c3dc1d8b944f9a3
test_bug795418-*.html depends on clipboard. But these tests aren't subsuite=clipboard and are sometimes failure (bug 1334700, bug 1335221, bug 1339430, bug 1343883 and bug 1348093). So we should move these to subsuite=clipboard to try fixing this.
MozReview-Commit-ID: 1m5dFGZ18a
--HG--
extra : rebase_source : 847b1b7842c32e93c61b8ee572cff16c70adc323
Since this step requires keyboard operation, we cannot create web-platform-test.
MozReview-Commit-ID: ExuaNOj9JG4
--HG--
extra : rebase_source : 0115e48fe1c3bdd7495e3bfc610f03ac1ee15ecb
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
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
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
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
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
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
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
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
Nicholas Nethercote
Makoto Kato
Yoshi Huang
Masayuki Nakano
Carsten "Tomcat" Book
Sebastian Hengst
Aryeh Gregor
Stone Shih
Christoph Kerschbaumer
Geoff Brown
Ehsan Akhgari
Olli Pettay
Florian Quèze
Mats Palmgren
Bas Schouten
Dan Banner