1808922 - [Gmail] Style is merged when text is copied from one row to another

Status: VERIFIED FIXED

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

Description

[Giorgia Nichita, Release Desktop QA]

Attachment: Gmail styles.gif

Found in

• Nightly 110.0a1

Affected versions

• 110.0a1
• 109.0b8
• 108.0.1

Affected platforms

• Ubuntu 22
• Windows 10
• macOS 10.14

Steps to reproduce

1. Go to https://mail.google.com and log in with a valid account.
2. Click on "Compose" to open up a new e-mail window.
3. Write 2-3 rows, each with a different style: Bold, Italic, Underline or Text color.
4. Copy the last row (or only part of it) and paste it at the end of the other rows.
5. Observe the style.

Expected result
The copied text is correctly pasted at the end of each row and it's style it's preserved.

Actual result
The copied text is pasted at the end of the rows but it's style is merged with the style of the rows it was pasted on.

Regression range

• Will look for one asap, if there is one.

Notes

• This behavior can also be observed when using Cut-Paste operation.
• Dragging & Dropping works as expected, the initial style of the row is preserved.
• Does not reproduce in Chrome.

Comment 1

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

It seems that Blink inserts pasted content into the nearest block element directly.
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/editing/commands/replace_selection_command.cc;l=1280;drc=41482404045cb6689ea898d109dbdcfe3365a529

Comment 2

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

Odd, we specify to clear the style at the insertion point...

Comment 3

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

Gmail cancels paste event, and do document.execCommand("insertHTML", false "...") for inserting the pasted content with perhaps sanitizing. At this time, we preserve the existing style at the insertion point.

Comment 4

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

Hmm, changing it to Clear causes only one "UNEXPECTED-PASS" in editing/run. This is too few. This means that there are no enough tests. I need to write some tests and confirm Chrome's behavior.

Comment 5

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

The inconsistent behavior was intentionally implemented in bug 587461 about 10 years ago. At that moment, Opera (Presto) behaved same as current Gecko. However, now, Gecko is the only browser engine of this behavior. Additionally, the behavior is inconsistent from the case of pasting content. This inconsistency causes that web apps cannot implement sanitizing pasting handler with canceling paste event and inserting safe content with execCommand("insertHTML"). Therefore, I believe that changing our behavior again must make sense.

Comment 6

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

FYI for Thunderbird folks: I'll change insertHTML command handler to make it work same as paste handler. If it's not suitable for Thunderbird users, let me know. I'll make it switchable with a new pref later.

Comment 7

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

Attachment: Bug 1808922 - Make `insertHTML` command handler clear inline styles for the new inserting content r=m_kato!

Currently, Gecko inserts content at insertion point as-is. However, Chrome
insert new content with splitting inline parents. Simply, this incompatibility
potentially causes different behavior from the other browsers. Additionally,
this behavior is different from the our paste handler itself. Therefore, web
apps cannot use execCommand("insertHTML") for inserting pasted content after
sanitizing its content and preventing the paste handler (this is what we see in
Gmail). Therefore, we should align the behavior to Chrome and use same
arguments as the our paste handler.

If Thunderbird users do not want this change, we need to make the behavior
switchable with a new pref later.

Depends on D168183

Comment 8

[Gregory Pappas [:gregp]]

Should this block bug 1341152?

Comment 9

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

Right.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d2558a9191ac
Make `insertHTML` command handler clear inline styles for the new inserting content r=m_kato

Comment 11

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

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

Comment 12

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/d2558a9191ac

Comment 13

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

Upstream PR merged by moz-wptsync-bot

Comment 14

[Dana Lucaci, Desktop QA]

Reproduced the issue with Firefox 110.0a1 (2023-01-06) using the steps from the description on MacOS 12.
The issue is verified fixed with Firefox 112.0a1 (20230226214053) and Firefox 111.0b6 (20230226190100) on Windows 10, macOS 12 and Ubuntu 22.