1998331 - button text-content cannot be selected (even in select-all)

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase.
2. Select-all (or click and drag to select from "Before" to "After")
3. Look visually at what's selected.
4. For good measure, copy-to-clipboard and paste elsewhere to see what the copied selection contained.

ACTUAL RESULTS:
Selection (and pasted output) does not include the button text.

EXPECTED RESULTS:
Selection (and pasted output) should probably include the button text.

Firefox gives ACTUAL RESULTS (in current Nightly 146.0a1 as well as very old Nightlies e.g. 2016-02-27 v47.0a1)
Current Chrome/Safari give EXPECTED RESULTS, as do old versions that I tested (Chrome 70 and Safari 13.1)

This seems to be the root cause of bug 1990445 (which involves selection by long-pressing on Android -- but I think it boils down to essentially this same "is the text selectable" question on Desktop)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (sort of a reference-case) with 'user-select: text'

If I give the button user-select: text, as in this variant of the testcase, then the STR give EXPECTED RESULTS in Firefox.

But this isn't a perfect reference for the interoperable behavior of the original testcase. In this variant, user-select: text also lets me click and drag inside the button to select just a portion of the button-text (in Chrome and Firefox at least) -- and that's not what any browser does on testcase 1.

Comment 2

[Daniel Holbert [:dholbert]]

It looks like this is because we have user-select: none on buttons.
https://searchfox.org/firefox-main/rev/cb52781342cc905eda923d009fc0b678f3a8c8c6/layout/style/res/forms.css#486-488,499

button,
::file-selector-button,
input:is([type="color"], [type="reset"], [type="button"], [type="submit"]) {
...
  user-select: none;

If I explicitly specify user-select: none on the button in the testcase, then other browsers switch to match our behavior.

So the issue here is largely that we have user-select: none; on buttons whereas other browsers do not.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (explicitly specified 'user-select:none', which makes other browsers match Firefox)

Comment 4

[Daniel Holbert [:dholbert]]

We've got the same behavior-difference for select as well. At least in that case, our user-select: none styling is explicitly backed up by the HTML standard:
https://html.spec.whatwg.org/multipage/rendering.html#the-select-element-2

The following styles are expected to apply to select elements when they are being rendered as a drop-down box with base appearance:

select {
[...]
  user-select: none;

I wonder why the html standard says that for select but not button...

Comment 5

[Daniel Holbert [:dholbert]]

It looks like our decl here for button dates back to ~2000-era, without any explanation or grounding in spec text, so maybe it's just legacy cruft that we can remove...

Comment 6

[Daniel Holbert [:dholbert]]

I'll give that a try, given that this is now known to affect impact user experience on two prominent sites (x.com and youtube.com).

Comment 7

[Daniel Holbert [:dholbert]]

Reassigning to salipov.

Tentatively, the steps here are:
(1) Remove the user-select: none; line of CSS linked in comment 2
(2) Recompile Firefox and make sure the testcases change behavior
(3) Decide whether we should do the same for select (see whether other browsers have user-select: none on that element
(4) Probably add a WPT test to check that getComputedStyle(someButton).userSelect is auto for an unstyled button.

And this will result in a better experience for Firefox-for-Android users on x.com and youtube.com, per blocked bugs. \o/

Comment 8

[Seva Alipov]

Removing the user-select: none; line does indeed make the buttons selectable by default, so that should be a valid fix.

I also did some digging and <select> elements don't have any working user-select functionality in Firefox, while in Chromium it seems to behave as though it has user-select: all;. I expect this should be a separate bug?

Writing a WPT will take me a while as I am quite new to this.

Comment 9

[David Shin[:dshin]]

FWIW, in the user-select spec:

The following additions are made to the UA stylesheet for HTML:
button, meter, progress, select { user-select: none; }

... But then again, bug 1990445 tells us that's maybe not interoperable.
See also: https://github.com/w3c/csswg-drafts/issues/9709

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Seva Alipov from comment #8)

Removing the user-select: none; line does indeed make the buttons selectable by default, so that should be a valid fix.

Rather than removing that line, I suspect we want to move it to a new CSS rule there, that has almost the same list of selectors, except not button.

(For other non-button button-flavored form-fields whose text is a browser-applied label -- e.g. <input type="submit"> -- it makes sense that the text shouldn't be selectable by default, I think; and that seems to match other browsers as described in https://github.com/w3c/csswg-drafts/issues/9709#issuecomment-2041439088 )

I also did some digging and <select> elements don't have any working user-select functionality in Firefox, while in Chromium it seems to behave as though it has user-select: all;. I expect this should be a separate bug?

That definitely seems like something to spin off to a separate bug, yeah. (Probably less pressing, since we're not aware of sites depending on it.) Thanks!

Comment 11

[Daniel Holbert [:dholbert]]

(let me know if you'd like me/David to file the select bug. I'll defer to you since you found it and maybe it's a good learning-the-ropes exercise to file a new bug with a testcase & steps-to-reproduce. :) )

Comment 12

[Seva Alipov]

Attachment: Bug 1998331: Making button element selectable by default r=dholbert,firefox-style-system-reviewers,emilio,devtools-reviewers,layout-reviewers,dshin,nchevobbe

Comment 13

[Seva Alipov]

Attachment: Bug 1998331: Making button element selectable by default r=dholbert

Comment 14

[David Shin[:dshin]]

Attachment: Minimum Reproducible Case for devtools browser_webconsole_context_menu_copy_entire_message.js failure

Comment 15

[David Shin[:dshin]]

Attachment: Minimum Reproducible Case for devtools browser_webconsole_context_menu_copy_entire_message.js failure

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f3477aafb445
https://hg.mozilla.org/integration/autoland/rev/a8be2ee40006
Making button element selectable by default r=dholbert,firefox-style-system-reviewers,emilio,devtools-reviewers,layout-reviewers,dshin,nchevobbe

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/69e11a76dd95
https://hg.mozilla.org/integration/autoland/rev/cf366d00ee90
Revert "Bug 1998331: Making button element selectable by default r=dholbert,firefox-style-system-reviewers,emilio,devtools-reviewers,layout-reviewers,dshin,nchevobbe" for causing browser failures at browser_text_selection.js

Comment 18

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

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

Comment 19

[rperta]

Backed out for causing browser failures at browser_text_selection.js
Backout link
Push with failures
Failure log(s)

Comment 20

[David Shin[:dshin]]

Interesting, likely is generating an additional AXSelectedTextChanged event that we need to handle around here.

Comment 21

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

Upstream PR was closed without merging

Comment 22

[Seva Alipov]

Should be fixed now

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/042bed283e8c
https://hg.mozilla.org/integration/autoland/rev/49922679114b
Making button element selectable by default r=dholbert,firefox-style-system-reviewers,emilio,devtools-reviewers,layout-reviewers,dshin,nchevobbe

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0f6710abe46c
https://hg.mozilla.org/integration/autoland/rev/32b9595c1fc6
Revert "Bug 1998331: Making button element selectable by default r=dholbert,firefox-style-system-reviewers,emilio,devtools-reviewers,layout-reviewers,dshin,nchevobbe" for causing mochitest failures @ browser_text_selection.js

Comment 25

[Norisz Fay [:noriszfay]]

Backed out for causing mochitest failures @ browser_text_selection.js

Backout link

Push with failures

Failure log

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9f7519efb8a7
https://hg.mozilla.org/integration/autoland/rev/c8c5e51b944f
Making button element selectable by default r=dholbert,firefox-style-system-reviewers,emilio,devtools-reviewers,layout-reviewers,dshin,nchevobbe

Comment 27

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

Upstream PR was closed without merging

Comment 28

[Cristian Tuns]

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

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Did you want to nominate this for the Fx155 relnotes? If so, set the relnote-firefox flag to "?"
https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination

Possible wording:

Fixed text inside buttons not being selectable or copyable, which prevented copying direct messages on X and comments on YouTube.

Comment 30

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

Upstream PR merged by moz-wptsync-bot

Comment 31

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

Upstream PR merged by moz-wptsync-bot

Comment 32

[Seva Alipov]

Release Note Request (optional, but appreciated)
[Why is this notable]: Fixed text inside buttons not being selectable or copyable, which prevented copying direct messages on X and comments on YouTube.
[Affects Firefox for Android]: Yes
[Suggested wording]: Fixed text inside buttons not being selectable or copyable, which prevented copying direct messages on X and comments on YouTube.
[Links (documentation, blog post, etc)]:

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx155 relnotes.