test_bug772796.html checks the behavior of joining <div> and <div style="white-space:pre">, but its expected results are different from the other browsers, and our behavior changes significant white-spaces/line breaks to collapsible white-spaces.

We should align the behavior to the other browsers if possible.

According to the other browsers' result in the new tests, it seems that we should handle joining <div> and <pre> cases in special paths for mail editor because Thunderbird's composer can create <pre> element by users and the joining may happen. However, the joining does not preserve white-space style in joined elements in the other browsers, but joining different white-space style <div> s does not have the issue with using <span style="white-space: foo">. Therefore, we should handle <pre> element case as the other browsers do in Firefox, but it's buggy behavior for Thunderbird users so that we should make same path for both cases in the mail editor.

Ah, no, <span style="white-space: pre"> isn't manageable from Thunderbird's UI. Perhaps, we should just maintain the white-spaces as-is from point of users.

And oddly, if <div> or <pre> has some non-default styles, <span style="white-space: pre> is used. I'll check Chromium's code.

This patch ports most part of editor/libeditor/tests/test_bug772796.html to
WPT because this kind of behaviors are not tested by editing/run/delete.html
nor editing/run/forwarddelete.html. (Not ported tests are invalid HTML
structure cases and list item cases, the reason why not doing this for the
latter is, it needs a lot of cases and not important for most web apps.)

The most expectations are based on Chrome and Safari (they both behave almost
same), but they fail a lot in join-pre-and-other-block.html and
white-space: pre-line cases in the other tests.

Even though this ports a lot of cases, for making easier to compare the
behavior change in the following patches, we should keep the tests.

Depends on D157409

This fixes bug 503838 partially. The new utility method scans unnecessary
<br> with strict check as far as possible. Then, we can delete the node or
the preformatted line break at end of the last text node.

Depends on D157410

Gecko just joins 2 blocks when editable block parents are same element, e.g.,
both are <div>. However, Chrome and Safari moves only first line of the
right block into the left block, and Gecko does it when both blocks are
different elements.

Ideally, we should take same behavior as Chrome and Safari because it's
reasonable for both compatibility with the other browsers and consistency
when both blocks are different but has same style, then we don't need to
maintain different behavior paths.

However, doing it for all elements are too risky because right block will be
merged into left block if right block has no line break. On the other hand,
without doing it, preserving white-space is really hard because we need to
maintain the both paths.

Therefore, I'd like to change the behavior only when both blocks have different
white-space styles. Usually, web apps do not change white-space for each
block, so I think that this is safer than doing this in all elements,
additionally, we can revert the behavior easy since this patch is really small.

Depends on D157411

Chrome and Safari preserve white-space with style attribute to keep
collapsible or preserved white-spaces as-is. If an HTML element is moved,
style attribute should be set to it. Otherwise, create <span> element
whose style attribute has the declaration for white-space and move
content into it.

Depends on D157412

We don't ignore invisible data node at joining 2 paragraphs and this is
a different behavior from the other browsers. When looking for a content
from current block boundary, AutoBlockElementsJoiner should keep scanning
visible things with ignoring invisible data nodes. Then, it should delete
all invisible things after joining the paragraphs.

Depends on D157413

Depends on D157414

Empty inline nodes except non-container nodes are not required in the
destination paragraph. Therefore, it should just remove the node from the
DOM tree.

Depends on D157415

When the first line of right block element is moved before the block element,
unnecessary line break may be moved to immediately before the right block
element. In the case, it needs to clean it up instead of trying to find
unnecessary line break at end of the left block which is a container of the
right block element.

Depends on D157416

It splits inline elements at the destination of first line in the right block.
However, it typically creates empty inline elements before the right block and
may be never used because it sets the insertion point to before the right node
of the splitting.

Therefore, it should stop creates empty inline elements (if they are required,
they should be created in HTMLEditor::MoveNodeOrChildrenWithTransaction
instead) and adjust split point after the element if it didn't split any nodes.

Depends on D157417

This is a hack for compatibility with the other browsers. When we move first
line of <pre> to left paragraph whose white-space style does not make it
preformatted, they drop the last linefeed because of unnecessary.

Depends on D157418

https://hg.mozilla.org/mozilla-central/rev/5678e20f87bd
https://hg.mozilla.org/mozilla-central/rev/821bcf805340
https://hg.mozilla.org/mozilla-central/rev/4dee35c73cda
https://hg.mozilla.org/mozilla-central/rev/7be1630c45ea
https://hg.mozilla.org/mozilla-central/rev/ff6fc48b40a7
https://hg.mozilla.org/mozilla-central/rev/50ef16cd0a8c
https://hg.mozilla.org/mozilla-central/rev/131c4fa45f0c
https://hg.mozilla.org/mozilla-central/rev/f3ed57cc2634
https://hg.mozilla.org/mozilla-central/rev/4146b092d9e7
https://hg.mozilla.org/mozilla-central/rev/2484b73438e2