Issue #1: indent/justify* can create non-valid fragments.
When applying a block-level formatting to a text node, Gecko creates a div or
blockquote block around the text node and sets the corresponding "align" or
"style" attribute. This patch checks that the active editing host can contain
such a block-level element.
Issue #2: indent/justify* can modify the active editing host.
On the first child of the editable element, the selection is extended outside of
the active editing host -- which causes a few issues for our test cases.
In this patch, this issue is "solved" by modifying
`nsHTMLEditRules::GetPromotedPoint' for block-level operations.
** About the tests **
Sorry for the long explanation but I prefer to be as sharp as possible when I
have to modify existing unit tests.
This patch raises 34 unit test "failures" which are improvements.
Two test files are concerned and have been modified accordingly:
* test_htmleditor_keyevent_handling
* test_richtext2.html
One test has been clarified (no real modification):
* test_bug414526.html
Of course, a specific unit test has been added, see `test_bug677752.html'.
** editor/libeditor/html/tests/test_htmleditor_keyevent_handling.html **
Outdenting now works properly, which results in 4 `FAIL'.
* 7372 ERROR TEST-UNEXPECTED-FAIL
| non-tabbable HTML editor: Shift+Tab after Tab on UL
- got "<ul><li id=\"target\">ul list item</li></ul>",
expected "<ul><ul><li id=\"target\">ul list item</li></ul></ul>"
* 7379 ERROR TEST-UNEXPECTED-FAIL
| non-tabbable HTML editor: Shift+Tab on UL
- got "ul list item",
expected "<ul><li id=\"target\">ul list item</li></ul>"
* 7415 ERROR TEST-UNEXPECTED-FAIL
| non-tabbable HTML editor: Shift+Tab after Tab on OL -
got "<ol><li id=\"target\">ol list item</li></ol>",
expected "<ol><ol><li id=\"target\">ol list item</li></ol></ol>"
* 7422 ERROR TEST-UNEXPECTED-FAIL
| non-tabbable HTML editor: Shfit+Tab on OL
- got "ol list item",
expected "<ol><li id=\"target\">ol list item</li></ol>"
** editor/libeditor/html/tests/browserscope/test_richtext2.html **
The 15 tests that now pass result in 15 `FAIL' and 15 `UNEXPECTED_PASS'.
Here's an overview of what we had before the patch:
* Section A - Apply Formatting Tests: +10 points
before patch: 21/31 (Selection: 9/31)
after patch: 28/31 (Selection: 12/31)
FB:BQ_TEXT-1_SI EXECUTION EXCEPTION
FB:BQ_TEXT-1_SI EXECUTION EXCEPTION
FB:BQ_BR.BR-1_SM EXECUTION EXCEPTION
FB:BQ_BR.BR-1_SM EXECUTION EXCEPTION
IND_TEXT-1_SI EXECUTION EXCEPTION
IND_TEXT-1_SI EXECUTION EXCEPTION
JC_TEXT-1_SC editing host is modified
JF_TEXT-1_SC editing host is modified
JL_TEXT-1_SC editing host is modified
JR_TEXT-1_SC editing host is modified
* Section AC - Apply Formatting Tests, using styleWithCSS: +5 points
before patch: 7/18 (Selection: 5/18)
after patch: 12/18 (Selection: 5/18)
IND_TEXT-1_SI editing host is modified
JC_TEXT-1_SC editing host is modified
JF_TEXT-1_SC editing host is modified
JL_TEXT-1_SC editing host is modified
JR_TEXT-1_SC editing host is modified
** editor/libeditor/html/tests/test_bug414526.html **
This test has been clarified to get more explicit report messages -- the test
themselves haven't been changed. A `todo_is' test has been added.
This test is the one that shows that `IsNodeInActiveEditor' can't be modified,
and that limiting the range promotion for block-level operations is preferrable.
Rationale: a command is supported if it can be converted to an internal Midas
command. `nsCommandManager::IsCommandSupported' might not be needed any more.
Corollary: document.queryCommandEnabled should return false on unsupported
commands without raising any exception.
Browserscope tests: +43 points = 258 failed tests...
* Q section: 0/48 => 42/48
42 tests used to fail (execution exception), now pass
* QE section: 36/46 => 37/46
garbage-1_TEXT-1 used to fail, now passes
In these two sections, a lot of tests that used to raise an exception now return
`false' (that's still a FAIL, but that's not the same kind of FAIL).
Other Browserscope tests are not affected by this patch.
The status of this test suite (currentStatus.js) has been updated accordingly.
Given the way GetPromotedPoint / IsNodeInActiveEditor are designed, when the
selection is in the first child element of the active editing host the
selection is extended outside of editor node.
As a result, `GetNodesFromSelection' (which is called at the beginning of
`WillAlign') returns two nodes:
1. an empty text node, which is enclosed in a <div style="text-align: ***">;
2. the first child element, which is destroyed when it's a <div>;
Proposed solution:
#1 can be avoided by checking that the node is editable in `WillAlign';
#2 can be avoided by not dropping <div> blocks in `RemoveAlignment'.
This is an opportunity to simplify `RemoveAlignment' a bit.
