36651dcbfe
Currently, the editor of Gecko always unwraps first line of the right child block after deleting selected range when the range starts in a parent block and ends in a child block. This behavior is almost same as the other browsers, but the other browsers deletes only preceding lines of the right child block (i.e., without unwrapping the first line of the right child block) if the range starts from start of a preceding line, for example, when deleting `<div>abc<br>[def<p>g]hi<br>jkl`, Gecko moves "hi" to the parent `<div>`, but the other browsers keeps it in the child `<p>`. For emulating this special handling, we need to touch 2 paths. One is `Backspace` when selection is collapsed at start of the child block. In this case, only when the preceding line is empty, i.e., there are 2 line breaks (either `<br>` or `\n` in `white-space: pre-*`), the following break should be deleted, but the child block should not be touched. The other is, deleting when selection is not collapsed or `Delete` when selection is collapsed at immediately before the child block. In the latter case, `HTMLEditor::HandleDeleteSelection` extends `Selection` using `nsFrameSelection`. Then, handle it with same path as deleting non-collapsed range. The former is handled with `HandleDeleteLineBreak` and `ComputeRangeToDeleteLineBreak`. The latter is handled with `HandleDeleteNonCollapsedRange` and `ComputeRangeToDeleteNonCollapsedRange`. The new handlers use the `ComputeRangeToDelete*`. Therefore, `beforeinput` reports exactly same range from `getTargetRanges`. However, existing paths do not use same approach and this patch makes `HandleDeleteNonCollapsedRange` fall it back to `HandleDeleteNonCollapsedRange`. Therefore, some `if` checks in `HandleDeleteNonCollapsedRange` are ugly, but I have no better idea to implement this smarter. Differential Revision: https://phabricator.services.mozilla.com/D207690
Most of this directory tests conformance to the editing spec written long ago by Aryeh Gregor. Nobody actually implements the spec, but the tests are still useful for regression testing. The files in data/ were generated from a JavaScript implementation of the specification using a complex procedure that can't actually be replicated right now as-is. Editing them manually is possible, but they're not really meant to be human-readable. If anyone is interested, it would be possible for Aryeh to get the test generation procedure working again. Or you could look into the repository history and figure out how to do it yourself, if you're brave. There is also a directory other/ that contains additional editor-related tests. They aren't necessarily based on any specification, but try to specify sensible behavior, and are meant to be helpful with regression testing for existing implementations and finding bugs in new implementations.