2011231 - m.youtube.com - Unable to copy comments, long tap does not trigger the context menu

Status: VERIFIED FIXED

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

Description

[Calin Tanase]

Environment:
Operating system: Android 16
Firefox version: Firefox Mobile [phone]

Steps to reproduce:

1. Go to https://m.youtube.com/watch?v=yUQ5BbHD_dI
2. Open the comments.
3. Long tap on a comment.

Expected Behavior:
Context menu appears.

Actual Behavior:
Context menu does not appear, unable to copy comment.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/202327

Comment 1

[Calin Tanase]

Attachment: long tap FF vs Chrome.mp4

Comment 2

[BugBot [:suhaib / :marco]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 3

[Titouan Thibaud [:titouan]]

The issue on Youtube is reproducible on Firefox Desktop by following those steps:

• Install https://addons.mozilla.org/en-GB/firefox/addon/uaswitcher
• Set the UserAgent to Firefox Android
• Load https://m.youtube.com/watch?v=yUQ5BbHD_dI
• Click on the first comment
• On the right pane that appears on the right, try to select the text of a comment

Expected result:
The text is selected

Actual result:
On Firefox Desktop, the "Report" popup appears.
On Firefox Android, nothing happens.

I think I have a minimal repro case, that I'll attach here.
I'm not an expert in this area, so take it with a grain os salt, but it does repro the same issue in the sense that:

• The text is selectable on Chrome (Desktop and Android)
• It is not selectable on Firefox (Desktop and Android)

If I understand correctly, the root cause seems to be the selection being disabled by CSS on an ancestor container of the comment text.

Is this already useful? Do you need any more help from me?

Comment 4

[Titouan Thibaud [:titouan]]

Attachment: repro.html

Comment 5

[Sky Schubert [:skyschub]]

Moving this to the layout team because the testcase in comment 4 is also reproducible on Desktop.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a reduced testcase. The key behavior-difference here is whether the "Auto-in-none" text is selectable (e.g. by double-clicking on desktop, or long-pressing on Android).

In Firefox on Desktop and Android, as well as Chrome on Desktop, it is not selectable.
In Chrome on Android, it is selectable.

So Chrome seems to be inconsistent on this behavior on Android vs. Desktop, and that inconsistency seems like a Chrome bug...

Comment 7

[Daniel Holbert [:dholbert]]

Related behavior-difference with testcase 2: if you load the testcase and do "select-all" (from Ctrl+A on desktop or e.g. long-press menu on the word "Auto"on Android), then:

• Firefox only selects "Auto"
• Chromium selects "Auto-in-none [SELECTABLE?]" up through "Auto".

For this scenario, Chromium is consistent between desktop and Android (and so is Firefox -- so we're consistently different-from-Chrome regardless of platform)

Comment 8

[Daniel Holbert [:dholbert]]

The spec here is: https://drafts.csswg.org/css-ui-4/#valdef-user-select-none

For user-select: none, the first sentence says The UA must not allow selections to be started in this element which basically describes our behavior. But then it goes into more details, and those details steer things in favor of Chrome's behavior:

• Quote: However, if this element has descendants on which the used value of user-select is not none, selections that start and end within these descendants are allowed. That seems to call for the Chrome-on-Android behavior described in comment 6.

• Quote: The UA must allow selections to extend across this element, and must exclude this element from such a selection. [...] If the element has descendants on which the used value of user-select is not none, these descendants must be included in a selection extending across the element. That seems to call for the Chrome behavior described in comment 7.

Comment 9

[Daniel Holbert [:dholbert]]

Oh right, auto is a magic sort-of-inheriting value -- quoting its spec text:
if the used value of user-select on the parent of this element is none, the used value is none
https://drafts.csswg.org/css-ui-4/#valdef-user-select-auto

So Firefox's behavior is correct here.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (comparing 'user-select' values inside of 'user-select:none')

Comment 11

[Daniel Holbert [:dholbert]]

Testcase 3 gets at this a bit more directly.

• Firefox allows you to select the last two lines only ("Text-in-none" and "All-in-none")
• Chrome allows you to select the 3rd-to-last line as well ("Auto-in-none"), and that's a Chrome bug.

So I think this is https://issues.chromium.org/issues/40499963 which is noting that Chrome implements this property incorrectly as being inherited. That issue was marked 'wontfix/obsolete', I think because Chromium devs expected it to be fixed by work that was already underway elsewhere. I just posted a comment asking if it could be reopened.

(See also the comment on the MDN user-select page which calls attention to the fact that it's implemented incorrectly in Chromium/WebKit as an inherited property: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/user-select )

Comment 12

[Daniel Holbert [:dholbert]]

sorry, I'd initially set site-bug based on the testcase -- but looking at the actual YouTube example, it's a bit more subtle than in the attached testcases.

As far as I can tell, YouTube doesn't explicitly set user-select here; instead it's just that the comments themselves are inside of <button> elements, and we have a user-agent stylesheet rule that adds user-select:none to buttons, as noted in bug 1998331 comment 2.

So this is platform bug 1998331 -- as explained in bug 1998331 comment 2, "the issue here is largely that we have user-select: none on buttons whereas other browsers do not."

We could hypothetically paper over this by adding user-select: auto on the button-elements in question here, either via a sitepatch or by asking Google/YouTube folks to add that style directly on their end.

Comment 13

[Daniel Holbert [:dholbert]]

This is sort-of fixed, in that you can now select the text, but I'm seeing a weird glitchy behavior that I filed as bug 2062388.

Comment 14

[Daniel Holbert [:dholbert]]

Actually I can't reproduce that glitchy behavior anymore (nor could dshin when he was just testing). We can keep chasing that in bug 2062388 if we figure out a way to reliably reproduce it. So I don't think that needs to block closing this bug anymore; the experience seems good now, and I think we're good to consider this FIXED by bug 1998331. \o/

Comment 15

[Calin Tanase]

Verified, the issue no longer reproduces.

Tested with:

• Browser / Version: Fenix 155.0-candidate build 1
• Operating System: Google Pixel 5 (Android 14)