unprefix -webkit-user-select

• Component: CSS
• Status: REOPENED ---

[Carlos Alberto Lopez Perez]

I think we should unprefix -webkit-user-select.

Firefox and Chrome support this CSS property "user-select" (without prefix) since a while [1].

So, I think we should unprefix it and make -webkit-user-select an alias to it (which its also required by the spec: https://www.w3.org/TR/css-ui-4/#propdef-user-select )


[1]
https://bugzilla.mozilla.org/show_bug.cgi?id=1492739
https://bugs.chromium.org/p/chromium/issues/detail?id=461018

[Maciej Stachowiak]

Is there any behavior difference between what we have and the standard version?

(Also we might need to add the unprefixed but keep the prefixed for web compat).

[Ryosuke Niwa]

(In reply to Maciej Stachowiak from comment #1)
> Is there any behavior difference between what we have and the standard
> version?
> 
> (Also we might need to add the unprefixed but keep the prefixed for web
> compat).

All the bug in "See Also" are good start like copying behavior.

[Sam Sneddon [:gsnedders]]

Given most web developers are largely blindly using -webkit-user-select alongside user-select today, do we need to block unprefixing on fixing our outstanding spec compliance issues?

[Radar WebKit Bug Importer]

<rdar://problem/86127924>

[Tim Nguyen (:ntim)]

Created attachment 457923 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 457923 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=457923&action=review

Please unprefix in all the UA stylesheets.

> Source/WebCore/css/CSSProperties.json:7284
> +            "status": "experimental",

Still true?

[Tim Nguyen (:ntim)]

Created attachment 457928 [details]
Patch

[Tim Nguyen (:ntim)]

(In reply to Simon Fraser (smfr) from comment #6)
> Comment on attachment 457923 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=457923&action=review
> 
> Please unprefix in all the UA stylesheets.

Done.

> > Source/WebCore/css/CSSProperties.json:7284
> > +            "status": "experimental",
> 
> Still true?

It's still in CSS UI 4, not in level 3. Level 4 is an editor's draft, so I would consider it experimental.

[Tim Nguyen (:ntim)]

Created attachment 457929 [details]
Patch

[Ryosuke Niwa]

We should fix https://bugs.webkit.org/show_bug.cgi?id=80159 before unprefixing this.

[Ryosuke Niwa]

(In reply to Tim Nguyen (:ntim) from comment #8)
> (In reply to Simon Fraser (smfr) from comment #6)
> > Comment on attachment 457923 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=457923&action=review
> > 
> > Please unprefix in all the UA stylesheets.
> 
> Done.
> 
> > > Source/WebCore/css/CSSProperties.json:7284
> > > +            "status": "experimental",
> > 
> > Still true?
> 
> It's still in CSS UI 4, not in level 3. Level 4 is an editor's draft, so I
> would consider it experimental.

I don't think the status of a spec matters much. If we're shipping it, and all other browsers have been shipping this feature, then for all practical purposes, it's a stable feature. There are enough web content dependent on this CSS property as is.

[Tim Nguyen (:ntim)]

Created attachment 457965 [details]
Patch

[Tim Nguyen (:ntim)]

Comment on attachment 457965 [details]
Patch

Just saw Ryosuke's comments

[Tim Nguyen (:ntim)]

(In reply to Ryosuke Niwa from comment #10)
> We should fix https://bugs.webkit.org/show_bug.cgi?id=80159 before
> unprefixing this.

I don't think we should be blocking on this. FWIW, the spec says that `user-select: none` is not a copy protection mechanism. 

We should fix this as a followup, and it sounds like something around VisibleSelection might need to be adjusted.

[Tim Nguyen (:ntim)]

Created attachment 457972 [details]
[fast-cq] Patch

[EWS]

Committed r293089 (249800@main): <https://commits.webkit.org/249800@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 457972 [details].

[Emilio Cobos Álvarez (:emilio)]

It seems unfortunate to unprefix this while keeping it as an inherited property instead of doing what the spec says (and Firefox does)?

[Tim Nguyen (:ntim)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)
> It seems unfortunate to unprefix this while keeping it as an inherited
> property instead of doing what the spec says (and Firefox does)?

Fixing this in bug 239514

[Wenson Hsieh]

So one interesting compat issue here is that we treat `user-select: all;` elements that would otherwise be editable as non-editable in (most) places in WebKit, whereas Firefox and Chrome don't (e.g. the fourth contenteditable div in whsieh.github.io/examples/user-select).

On iOS 16 beta, this causes the body field to be non-editable when composing an email in Outlook (outlook.live.com).

[Tim Nguyen (:ntim)]

(In reply to Wenson Hsieh from comment #19)
> So one interesting compat issue here is that we treat `user-select: all;`
> elements that would otherwise be editable as non-editable in (most) places
> in WebKit, whereas Firefox and Chrome don't (e.g. the fourth contenteditable
> div in whsieh.github.io/examples/user-select).
> 
> On iOS 16 beta, this causes the body field to be non-editable when composing
> an email in Outlook (outlook.live.com).

Can you please file a new bug with a reduced testcase? That does seem like a bug to me.

[Wenson Hsieh]

(In reply to Tim Nguyen (:ntim) from comment #20)
> (In reply to Wenson Hsieh from comment #19)
> > So one interesting compat issue here is that we treat `user-select: all;`
> > elements that would otherwise be editable as non-editable in (most) places
> > in WebKit, whereas Firefox and Chrome don't (e.g. the fourth contenteditable
> > div in whsieh.github.io/examples/user-select).
> > 
> > On iOS 16 beta, this causes the body field to be non-editable when composing
> > an email in Outlook (outlook.live.com).
> 
> Can you please file a new bug with a reduced testcase? That does seem like a
> bug to me.

Filed: <https://bugs.webkit.org/show_bug.cgi?id=242006>.

The reduced test case is just `<div contenteditable style='user-select: all;'>`.

[Tim Nguyen (:ntim)]

Reverted by https://github.com/WebKit/WebKit/commit/e4b63beaeb743e2d311d689590ec49bb0728b3ff

[Ahmad Saleem]

I think JIRA is also one of the product having this issue as below:

https://jira.atlassian.com/browse/JRACLOUD-76566

Specifically this comment - https://jira.atlassian.com/browse/JRACLOUD-76566?focusedCommentId=3136522&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-3136522

They are using inline CSS on span with "user-select: none;" and not "-webkit-user-select: none".

Just wanted to update. Thanks!