Add tests for contenteditable=false elements inside contenteditable=true elements and for selection in empty elements

[Comandeer]

I've been asked by @johanneswilm to prepare some tests for selection issues in CKEditor as a part of Interop 2022.

There are two main issues for us:

• selection of the [contenteditable=false] elements inside the [contenteditable=true] elements (especially at their beginning and end),
• placing selection inside empty elements.

Tests

For the first issue I've prepared 4 tests:

• automatic:
  • selection/contenteditable/cefalse-on-boundaries.html,
• manual:
  • editing/cefalse-beginning-deletion-manual.html,
  • editing/cefalse-boundaries-deletion-manual.html,
  • editing/cefalse-end-deletion-manual.html.

Unfortunately, manual tests were needed because Chrome shows the correct selection and it seems to work fine with the JS API (e.g. range#deleteContents()) but trying to interact in person with such selection results in a broken experience (the selected content can't be deleted).

For the issue with putting selection inside empty elements, I've prepared two tests:

• automatic:
  • selection/caret/empty-elements.html,
• manual:
  • editing/empty-elements-manual.html.

Once again, a manual test was needed as Firefox allows putting the selection inside such an element but typing inside it does not work (the typed content is moved outside the empty element).

Context

The first issue required us to create dedicated plugins for CKEditor 4 and CKEditor 5 whose task is to add editable elements around non-editable ones (especially ones at the beginning or end of the editor) to fix the incorrect selection of them. However, in CKE4, even with this plugin, the issue is still present, especially in Safari.

The second one requires us to use various fillers (CKEditor 4 version and CKEditor 5 one)  to be able to put the selection in such places. There is also a similar issue connected with editing at the edge of elements, e.g. links. As visible in CKEditor's 5 link demo, putting the caret inside any of the links, moving it to the end of the link, and pressing space will produce an   filler, needed to inform the browser that the intention is to stay inside the link.

[jgraham]

@masayuki-nakano could you look at these tests? https://wpt.fyi/results/selection?label=pr_head&max-count=1&pr=35862 suggests that the cases covered are where Blink and Gecko agree but WebKit is different.

[masayuki-nakano]

Currently, Gecko allows to delete non-editable nodes which are children of editable nodes. https://searchfox.org/mozilla-central/rev/7b36c8b83337c4b4cdfd4ccc2168f3491a86811b/editor/libeditor/HTMLEditUtils.h#103-119

And creating new text node when selection is collapsed in an empty element is reasonable to me. However, I'm not sure about the cases when selection range boundary is in an empty inline element, e.g.,

abc<strong>[</strong>d]ef

In this case, abc<strong>[new text</strong>ef is expected? Or abc<strong></strong>new textef?

Similarly,

ab[c<strong>]</strong>def

In this case, abnew textdef? abnewtext<strong></strong>def or ab<strong>new text</strong>def?

I think that in the Chrome's rules, the first expectations are reasonable because Chrome keeps the style of start boundary of the range as far as I've investigated.

[Comandeer]

I think that in the Chrome's rules, the first expectations are reasonable because Chrome keeps the style of start boundary of the range as far as I've investigated.

I tend to agree with Chrome on that – keeping the style of start boundary is something we do in CKEditor.

I've also added an additional test for inserting text on the boundaries of a link – browsers jump out of the link, even if the range is still inside it. It's inconsistent with other elements, e.g. strong where the same selection stays inside the element upon inserting anything.

@masayuki-nakano, thanks for the review! I've updated the PR according to your advice. Thanks to that I was able to move all tests into two files: editing/empty-elements-insertion.html and editing/cefalse-boundaries-deletion.html. Could you recheck if everything's ok?

[masayuki-nakano]

I apologize the long delay.

I think that in the Chrome's rules, the first expectations are reasonable because Chrome keeps the style of start boundary of the range as far as I've investigated.

I tend to agree with Chrome on that – keeping the style of start boundary is something we do in CKEditor.

Well, but it's something a little bit complicated if first visible content is not text, e.g., <img>.

I've also added an additional test for inserting text on the boundaries of a link – browsers jump out of the link, even if the range is still inside it.

I don't think it's reasonable because it makes it impossible that web apps cannot make users keep tying in a link with managing Selection. Therefore, I think that if Selection is updated by Selection API (including Range API), the position should be used as-is. Then, it provides better ability to web apps.

FYI: Gecko does something special in this case, but for compatibility with the other browsers and traditional behavior which is important for Thunderbird. Gecko respects Selection when caret is moved from inside a link to the link edge by right or left arrow key or user clicks outer half of the character at edges of a link. (I don't think that this native behavior of browsers should be aligned.)

It's inconsistent with other elements, e.g. strong where the same selection stays inside the element upon inserting anything.

Yeah, I don't like the inconsistent behavior because browsers need to handle it specially in some places in builtin editor implementation. However, I think that the inconsistency comes from traditional behaviors of some word processors especially "Word". Therefore, I think that the special handling may be expected by the users.

@masayuki-nakano, thanks for the review! I've updated the PR according to your advice. Thanks to that I was able to move all tests into two files: editing/empty-elements-insertion.html and editing/cefalse-boundaries-deletion.html. Could you recheck if everything's ok?

Really sorry for the long delay. I'll check it soon.

[masayuki-nakano]

FYI: I'm not a formal reviewer of WPT. Therefore, I'm not sure about the details of the rules around the test message, formatting the code (especially around the white-spaces around ()).

And perhaps, these tests should be in editing/run or editing/other because there is only one test under editing directly. I'm not sure how to group run and other, but run contains tests of various execCommand. Therefore, I usually add tests under editing/other when I add new tests at fixing a bug of Gecko.

[wpt-pr-bot]

There are no reviewers for this pull request. Please reach out on the chat room to get help with this. Thank you!

[Comandeer]

However, I think that the inconsistency comes from traditional behaviors of some word processors especially "Word". Therefore, I think that the special handling may be expected by the users.

Yes, that sounds like a plausible explanation for the current link behavior.

@masayuki-nakano, thanks for the review. I've further updated the tests, following your advice.

[jgraham]

FYI: I'm not a formal reviewer of WPT. Therefore, I'm not sure about the details of the rules around the test message, formatting the code (especially around the white-spaces around ()).

There aren't strongly enforced rules for js formatting because we don't have a toolchain to enforce them, and we have contributions coming from multiple projects, and don't want things to be blocked on formatting choices.

So generally it's up to your discretion, but of course code that looks like the surrounding code is better than code that's introduces new conventions.