1747008 - Page jumps at the top of editor after pasting text while using WikEd on wikipedia

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Ksenia Berezina [:ksenia]]

Attachment: 94036.html

We've got a report in https://github.com/webcompat/web-bugs/issues/94036 about a problem with pasting text into WikEd editor while editing articles on Wikipedia. After pasting text, the cursor in contenteditable area gets moved to its starting point. The problem is severe on pages with a lot of content as it takes time to scroll back to the pasted text.

The editor is wrapping pasted text with two <span> elements with execCommand("insertHtml"). In Firefox the second <span> is missing after insertion, but the editor is relying on it to be in the DOM for further steps.

I've created a reduced test case to demonstrate the behaviour (for simplicity, only clicking inside contenteditable area is enough).

STR:

1. Load the attached testcase and click inside contenteditable area
2. Observe the message below

Expected:
"span with id wikEdScrollAfter is present"
Actual:
"span with id wikEdScrollAfter is missing"

This appears to be regressed by https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a67baeba9a658f8650657389f38aa9bc7e2eef07&tochange=f895a0b6c0e3748e11381173b3cd32a7bb8c60dd

Comment 1

[Ksenia Berezina [:ksenia]]

Hi Masayuki, could you please look into this?

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1730429

Comment 3

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

I see, we shouldn't delete empty inline elements if they are inserted intentionally.

Comment 4

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

I checked what is different from Chrome quickly. The main difference for this bug is, Chrome collapse selection to the end of last text node of inserted HTML fragment. And if there is no text nodes in inserted HTML fragment, Chrome keeps caret at end of split text node before insertion point.

Following this behavior can fix this bug, but I'm really feel it's odd behavior. Perhaps, collapsing selection to after the inserted HTML fragment must be better to match with users' expectation...

Comment 5

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

Attachment: Bug 1747008 - Make `HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal` stop stripping empty inline elements if they may be inserted intentionally r=m_kato!

Starting from bug 1730429, we strip empty inline elements at caret for
compatibility with Blink/WebKit. However, we should not do it for the elements
which are intentionally inserted (from inserthtml command, paste and DnD).

All the cases are handled by HTMLEditor::HTMLWithContextInserter so that
it should prevent the new clean up with TopLevelEditSubActionData.

Note that inserthtml command handling of Blink is really odd. It inserts
the empty inline elements of the adding testcases into different place so that
Chrome does not pass the new tests. However, it does not make sense and I
believe that it's out of scope of this bug.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/52f631e145e8
Make `HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal` stop stripping empty inline elements if they may be inserted intentionally r=m_kato

Comment 7

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/32283 for changes under testing/web-platform/tests

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/52f631e145e8

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 10

[Monica Chiorean]

I was able to reproduce the issue on Win10 using build 96.0a1 (20211128092809) an steps from description.
Verified as fixed on Win10 / Mac 10.13 / Ubuntu 20.4 using build 97.0b5 (20220118185733).