Closed
Bug 1492739
Opened 7 years ago
Closed 6 years ago
Consider unprefixing -moz-user-select
Categories
(Core :: CSS Parsing and Computation, defect, P4)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
mozilla69
Tracking | Status | |
---|---|---|
firefox69 | --- | fixed |
People
(Reporter: jgruen, Assigned: emilio)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-complete, parity-chrome, site-compat)
Attachments
(3 files)
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.
Reporter | ||
Updated•7 years ago
|
Summary: user-selec CSS rule does not work without a prefix → user-select CSS rule does not work without a prefix
Assignee | ||
Comment 1•7 years ago
|
||
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
Assignee | ||
Updated•7 years ago
|
Component: Layout: Text and Fonts → CSS Parsing and Computation
Comment 2•7 years ago
|
||
(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)
Assignee | ||
Comment 3•7 years ago
|
||
Looks like this comes way back to bug 1211101.
Comment 4•7 years ago
|
||
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•7 years ago
|
||
(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•7 years ago
|
||
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•7 years ago
|
||
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•7 years ago
|
||
A related question, is unshipping -moz-user-select feasible at this point?
Comment 9•7 years ago
|
||
(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•7 years ago
|
||
OK, I filed bug 1492958 for aligning our web-exposed values with Chrome
before we consider unprefixing.
Severity: normal → enhancement
Priority: -- → P4
Comment 11•6 years ago
|
||
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?
Assignee | ||
Comment 13•6 years ago
|
||
Will send a combined intent to implement / ship for this and bug 1492958.
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → emilio
Keywords: site-compat
Updated•6 years ago
|
Keywords: dev-doc-needed
Comment 15•6 years ago
|
||
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)
Assignee | ||
Comment 16•6 years ago
|
||
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.
Updated•6 years ago
|
Attachment #9024308 -
Attachment description: Bug 1492739 - Unprefix user-select. → Bug 1492739 - Unprefix user-select. r=mats
Assignee | ||
Comment 17•6 years ago
|
||
Depends on D11585
Comment 19•6 years ago
|
||
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
Comment 20•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/807e0fabd519
https://hg.mozilla.org/mozilla-central/rev/d806a12ca468
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox69:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
Comment 21•6 years ago
|
||
Posted site compatibility note: https://www.fxsitecompat.dev/en-CA/docs/2019/user-select-has-been-unprefixed/
Comment 22•6 years ago
|
||
BCD was already updated by someone before I got to it. I've added a note to Firefox 69 for developers.
Keywords: dev-doc-needed → dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•