2007618 - Caret position confused after backspace delete, leading to erroneous further deletions (part 2)

Status: ASSIGNED

(Core :: DOM: Editor, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oddly, we still reproduce the bug in attachment 9532874 [details] even though the similar tests in bug 2005895 pass.

Original report:

This happening in Firefox 140 ESR, but also current Nightly.

STR:
Open the attached HTML document.
Place the cursor into the third empty line.
Press backspace, observe the cursor position, press backspace again.

Actual:
After the first backspace the caret is at the beginning of the second line. (When run in Thunderbird, the cursor disappears completely.)
After the second backspace, the full stop (.) at the end of the second line is deleted.

Variation:
Open the attached HTML document.
Place the cursor into the third empty line.
Press backspace, observe the cursor position, type a letter.
Again, after the first backspace, the cursor location is confused, typing a letter goes back to the third line.

Expected:
After the first backspace, the caret should be at the end of the second line.

Alice, is this a regression? This erroneous behaviour seems new.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Okay, the remaining issue is the case that a white-space only Text is there between the paragraphs like:

<p>abc<br> </p> <p>{}<br></p>

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 2007618 - Make `AutoEmptyBlockAncestorDeleter::GetNewCaretPosition` ignore invisible `Text` nodes r=m_kato!

The remaining case of bug 2005895 is, there is a invisible Text
between paragraphs like:

<p>abc</p> <p>{}<br></p>

The reason is, HTMLEditUtils::GetPreviousContent is not called with
WalkTreeOption::IgnoreWhiteSpaceOnlyText. Therefore, I tried to
add the option in AutoEmptyBlockAncestorDeleter::GetNewCaretPosition.
However, the handling is odd [1]:

  static bool IsContentIgnored(const nsIContent& aContent,
                               const WalkTreeOptions& aOptions) {

<snip>

    if (aOptions.contains(WalkTreeOption::IgnoreWhiteSpaceOnlyText) &&
        aContent.IsText() &&
        const_cast<Text*>(aContent.AsText())->TextIsOnlyWhitespace()) {
      return true;
    }

So, whether the Text is actually visible or not is not tested.
Therefore, this does not work with preformatted content. However, I'd
like to uplift this to ESR140 so that it's too risky to change the
extant HTMLEditUtils implementation. Therefore, this patch makes
GetNewCaretPosition ignore invisible Text nodes directly.

1. https://searchfox.org/firefox-main/rev/20a1fb35a4d5c2f2ea6c865ecebc8e4bee6f86c9/editor/libeditor/HTMLEditUtils.h#3268-3269,3279-3282

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

FYI: HTMLEditUtils::IsContentIgnored will be removed in bug 1996500.