1891427 - The sheet tab name is not correctly displayed after dragging some text inside Google Sheets

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: google_.gif

Found in

• 126.0a1 (2024-04-14)

Affected versions

• 126.0a1 (2024-04-14)
• 125.0
• 115.10.0esr

Tested platforms

• Affected platforms: Windows 10x64, macOS 12
• Unaffected platforms:, Ubuntu 23.10 (text cannot be dragged)

Steps to reproduce

1. Open Google Sheets and select some text from the sheet tab name.
2. Drag the text to the left or right.

Expected result

• The sheet tab name is correctly displayed.

Actual result

• The sheet tab name is not correctly displayed.

Regression range

• Reproducible with 55.0a1 (2017-04-12). I think it's safe to assume that this is not a regression

Additional notes

• Attached a screen recording..

Comment 1

[Thomas Wisniewski [:twisniewski]]

Dragging a selection of the title text seems to be working for me on the latest nightly, so this might be fixed.

:atrif, could you confirm if it's also working for you now?

Comment 2

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: sheet_0.gif

(In reply to Thomas Wisniewski [:twisniewski] from comment #1)

Dragging a selection of the title text seems to be working for me on the latest nightly, so this might be fixed.

:atrif, could you confirm if it's also working for you now?

Hello! I can still reproduce the issue with the latest Nightly 132.0a1 (2024-09-16) on Windows 10x64. Attaching a screen recording.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing devtools view of DOM when this happens

This seems to be a contenteditable thing.

In Firefox (on Windows), when you drag-and-drop the text, you end up getting a new <span> that's a child of the other one, and that inner span has all the same classes and hence gets the same outline/etc. That's the problem here.

In Chrome, when you drag-and-drop the text, it just directly rearranges inside of the existing <span>. No new span gets created there.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screencast of behavior difference with reduced testcase 1

Here's a screencast showing the attached reduced testcase in Chrome vs. Firefox.

Chrome doesn't generate a new span when I drag-and-drop text. (It does insert a <br> in this particular case which happens to create a linewrap with some overlap in this case -- but they avoid that on the actual live site.)

Whereas Firefox generates a new nested span when I drag-and-drop here.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

Chrome doesn't generate a new span when I drag-and-drop text. (It does insert a <br> in this particular case which happens to create a linewrap with some overlap in this case -- but they avoid that on the actual live site.)

Ah, interesting -- on Google Sheets, they use the prefixed feature -webkit-user-modify: read-write-plaintext-only; which seems to be responsible for them not-inserting-br-elements there.

We don't have any bugs on that, but it's mentioned in MDN (as a deprecated property) here:
https://developer.mozilla.org/en-US/docs/Web/CSS/user-modify

So: there are two compat differences here:
(1) When you drag-and-drop text, Firefox generates a new span, whereas Chrome inserts a <br> into the existing span. (This means we get another layer of span styling, e.g. a duplicate border in this case.)
(2) If we were to hypothetically adopt Chrome's exact behavior on that point and keep the existing span with a new br, we would need to also implement -webkit-user-modify: read-write-plaintext-only as a means to suppress those unexpected <br> elements when a user does this dragging-and-dropping in Google Sheets.

Comment 8

[Daniel Holbert [:dholbert]]

We might consider doing outreach to Google Docs folks here -- they can avoid this (and avoid the need to lean on -webkit-user-modify: read-write-plaintext-only) by putting contenteditable on a block-level div wrapper, I think. (Or something along those lines...)

Comment 9

[Raul Bucata]

The issue has been fixed.

Tested with:

Browser / Version: Firefox Nightly 138.0a1 (2025-03-23) (64-bit)
Operating System: Windows 10 PRO x64

Comment 10

[Raul Bucata]

Attachment: fixed issue on Firefox Nightly

Comment 11

[Raul Bucata]

Verified as FIXED using the RC Build

Tested with:

Browser / Version: Firefox 137.0-candidate build 1
Operating System: Windows 10 PRO x64