Closed Bug 1492739 Opened 6 years ago Closed 5 years ago

Consider unprefixing -moz-user-select

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla69
Tracking Status
firefox69 --- fixed

People

(Reporter: jgruen, Assigned: emilio)

References

(Blocks 1 open bug, Regressed 1 open bug)

Details

(Keywords: dev-doc-complete, parity-chrome, site-compat)

Attachments

(3 files)

Attached image 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.
Summary: user-selec CSS rule does not work without a prefix → user-select CSS rule does not work without a prefix
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).
Flags: needinfo?(mats)
Summary: user-select CSS rule does not work without a prefix → Consider unprefixing -moz-user-select
Component: Layout: Text and Fonts → CSS Parsing and Computation
(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.
Flags: needinfo?(mats)
Looks like this comes way back to bug 1211101.
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.
(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.
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.)
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?
A related question, is unshipping -moz-user-select feasible at this point?
(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.)
Depends on: 1492958
OK, I filed bug 1492958 for aligning our web-exposed values with Chrome
before we consider unprefixing.
Severity: normal → enhancement
Priority: -- → P4
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?
Keywords: parity-chrome
OS: Mac OS X → All
Hardware: Unspecified → All
Will send a combined intent to implement / ship for this and bug 1492958.
Assignee: nobody → emilio
Keywords: site-compat
Depends on: 1506547
Blocks: unprefix

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?

Flags: needinfo?(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.

Attachment #9024308 - Attachment description: Bug 1492739 - Unprefix user-select. → Bug 1492739 - Unprefix user-select. r=mats

Rebased + did some related cleanup.

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

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

Regressions: 1595905
Regressions: 1639041
No longer regressions: 1639041
Regressions: 1842684
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: