deleteSoftLineBackward (command+delete) deletes text from previous block

[javan]

Steps to Reproduce

1. Type a few lines of text
2. Press ⌘delete to remove each line
3. Note that the cursor incorrectly moves to the previous line and removes some of its text

Details

• Trix version: 1.2.0
• Browser name and version: Chrome 76 (works correctly in Safari)

[stale[bot]]

This issue has been automatically marked as stale after 90 days of inactivity. It will be closed if no further activity occurs.

[ilias-t]

The issues appears to be with the values Chrome is returning for the static range of this event. They both implement Input Events Level 2, so they should be comparable.

Given the following text:

The quick
brown fox
jumps over
the lazy
fox.

Placing the caret after the period and hitting backspace with the meta key produces the following in each browser...

Safari ✅

The quick
brown fox
jumps over
the lazy

Chrome 🚫

The quick
brown fox
jumps over
the l

When calling getTargetRanges on the respective events, and picking the first one from the list, the a static range is returned with the following fields:

Safari

collapsed: false
endContainer: #text "dog."
endOffset: 4
startContainer: #text "dog."
startOffset: 0

Chrome

collapsed: false
endContainer: text
  textContent: “dog."
endOffset: 4
startContainer: text
  textContent: "the lazy"  // 🤔
startOffset: 5 // 🤔

Note the difference between the startContainer and startOffset values.

The zeroth position of the start container "dog." is going to delete the entire line (Safari), while the fifth position of the start container "the lazy" is going to remove the fifth character "a", but leave the remaining (Chrome). Trix uses these values to figure out the range of text that should be removed and these numbers are consistent with the observed behavior in each browser.

As an aside, it's worth mentioning that Chrome sends deleteHardLineBackward, while Safari sends deleteSoftLineBackward. However, that difference, while odd, should be inconsequential for Trix as it doesn't depend on the inputType of "beforeinput" events; it only cares about the calculated range.

After a few searches for related bugs in the Chromium project, I wasn't able to find an issue that matched this case well, but did find some related ones: 26119, 650722, 820947. In the mean time, I'll wait for someone to verify these findings before filing a new issue in the project.

[javan]

Excellent investigation, @ilias-t! I can verify and help illustrate your findings. The reports below show the the target ranges mapped to their nodes and offsets:

✅ Safari: https://input-inspector.now.sh/profiles/3fzHxqIH4pi8ZxqswhbO

🚫 Chrome: https://input-inspector.now.sh/profiles/FUuTpVP9u4NpbmeARemS

Chrome's target ranges are clearly wrong and don't match the text that's ultimately removed. Note: https://input-inspector.now.sh uses a plain contenteditable element with no additional JavaScript behavior, which rules out Trix as a culprit.

Definitely should be reported upstream to Chromium! Are you interested in taking that on?

[ilias-t]

Sure thing, filed https://bugs.chromium.org/p/chromium/issues/detail?id=1043564