1492739 - Consider unprefixing -moz-user-select

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P4)

Description

[John Gruen [:jgruen]]

Attachment: example behavior

I am not able to set user-select rules in Firefox 64.0a1 on MacOS. There may be places where this works, but i a have been able to reproduce the issue on multiple domains targeting various tags.

STR
* Go to any website
* Open the inspector and target an element
* In the css inspector add `user-select: none` to the element

Expected
* The new rule will be picked up, and applied to element

Actual
* Firefox tells me the rule is invalid


Using `-moz-user-select` fixes the issue.


Note: This is only on STR, i have been able to reproduce this using sandalone stylesheets as well.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Yeah, we only implement it as -moz-user-select, or -webkit-user-select. Mats, do you happen to have the context about why it ended up this way?

Given other engines ship it unprefixed we may as well do that unless there are known compat issues (but in that case I don't get why we alias the -webkit- prefix).

Comment 2

[Mats Palmgren (inactive)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)
> Mats, do you happen to have the context about why it ended up this way?

Not really.  It appears Xidorn added -webkit-user-select in:
https://searchfox.org/mozilla-central/diff/75b88db85d48bde6b72f7be644f88c431cc4a5d0/servo/components/style/properties/longhand/ui.mako.rs#20
https://github.com/servo/servo/pull/14939

I can't tell what the reason was from that issue and I can't find
any discussion / bug / intent-to-ship in dev.platform either. :(
Maybe we shipped it by mistake?


> Given other engines ship it unprefixed we may as well do that unless there
> are known compat issues (but in that case I don't get why we alias the
> -webkit- prefix).

If we're compatible with Chrome/Safari, then I don't see a problem with us
unprefixing it too.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Looks like this comes way back to bug 1211101.

Comment 4

[Mats Palmgren (inactive)]

So bug 837211 is the origin I guess?  I don't see any discussion
there about -webkit-user-select specifically so I don't know
the reasons why it was included.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Mats Palmgren (:mats) from comment #4)
> So bug 837211 is the origin I guess?

That's where we added support for the -webkit prefixed version, yeah.

> I don't see any discussion there about -webkit-user-select specifically
> so I don't know the reasons why it was included.

I'm guessing it was due to usage data.  https://www.chromestatus.com/metrics/css/timeline/popularity/339 indicates that ~79.58% of pages loaded (in Chrome at least) use this feature, by its -webkit prefixed name.

Comment 6

[Daniel Holbert [:dholbert]]

er sorry, I meant to share this link for a simple view of its frequent-usage: https://www.chromestatus.com/metrics/css/popularity

(Though that other /timeline/ one also demonstrates its high usage over time, too.)

Comment 7

[Mats Palmgren (inactive)]

That's all good, but did we do any compatibility analysis of
the -webkit-user-select values at the time?

At first glance, it seems Chrome only supports all/none/auto/text whereas
we also support -webkit-user-select:element/elements/tri-state/toggle/...
We should probably try to unship values not supported in other UAs.

Do we know if the values we do share actually behave the same way?

Comment 8

[Mats Palmgren (inactive)]

A related question, is unshipping -moz-user-select feasible at this point?

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Mats Palmgren (:mats) from comment #7)
> That's all good, but did we do any compatibility analysis of
> the -webkit-user-select values at the time?

I'm not sure, but I suspect not much of one (other than to observe that enabling the webkit-prefixed alias didn't seem to cause regression bug-reports).

(I don't have any other answers to comment 7, though I agree with your sentiment in general that we should unship nonstandard/non-compatible bits if possible.)

Comment 10

[Mats Palmgren (inactive)]

OK, I filed bug 1492958 for aligning our web-exposed values with Chrome
before we consider unprefixing.

Comment 11

[Gingerbread Man]

This is a duplicate of bug 1359778, which has a 2-year old patch. Should it be marked as such, or should that be forward-duped to this?

Comment 13

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1492739 - Unprefix user-select. r=mats

Will send a combined intent to implement / ship for this and bug 1492958.

Comment 15

[Brian Birtles (:birtles)]

Emilio, are the differences Florian pointed out ("inherited vs not, initial value of auto, different between 'auto' and 'text'") still blocking us from unprefixing this? Or was that all covered by bug 1506547?

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Yeah, it's covered by that and the resolution in https://github.com/w3c/csswg-drafts/issues/3344, so we're following the spec now, will land this.

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1492739 - Unprefix usage of -moz-user-select from UA stylesheets. r=mats

Depends on D11585

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Rebased + did some related cleanup.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/807e0fabd519
Unprefix user-select. r=mats
https://hg.mozilla.org/integration/autoland/rev/d806a12ca468
Unprefix usage of -moz-user-select from UA stylesheets. r=mats

Comment 20

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/807e0fabd519
https://hg.mozilla.org/mozilla-central/rev/d806a12ca468

Comment 21

[Kohei]

Posted site compatibility note: https://www.fxsitecompat.dev/en-CA/docs/2019/user-select-has-been-unprefixed/

Comment 22

[Eric Shepherd [:sheppy]]

BCD was already updated by someone before I got to it. I've added a note to Firefox 69 for developers.