REOPENED 208677
unprefix -webkit-user-select
https://bugs.webkit.org/show_bug.cgi?id=208677
Summary unprefix -webkit-user-select
Carlos Alberto Lopez Perez
Reported 2020-03-05 17:02:50 PST
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
Attachments
Patch (24.70 KB, patch)
2022-04-19 12:03 PDT, Tim Nguyen (:ntim)
simon.fraser: review+
ews-feeder: commit-queue-
Patch (24.70 KB, patch)
2022-04-19 12:27 PDT, Tim Nguyen (:ntim)
no flags
Patch (29.96 KB, patch)
2022-04-19 12:29 PDT, Tim Nguyen (:ntim)
ews-feeder: commit-queue-
Patch (31.00 KB, patch)
2022-04-20 00:33 PDT, Tim Nguyen (:ntim)
ntim: commit-queue-
[fast-cq] Patch (32.91 KB, patch)
2022-04-20 03:39 PDT, Tim Nguyen (:ntim)
no flags
Maciej Stachowiak
Comment 1 2020-03-06 21:50:30 PST
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
Comment 2 2020-03-06 22:23:59 PST
(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]
Comment 3 2021-08-13 10:16:21 PDT
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
Comment 4 2021-12-06 15:53:52 PST
Tim Nguyen (:ntim)
Comment 5 2022-04-19 12:03:17 PDT
Simon Fraser (smfr)
Comment 6 2022-04-19 12:13:38 PDT
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)
Comment 7 2022-04-19 12:27:49 PDT
Tim Nguyen (:ntim)
Comment 8 2022-04-19 12:29:08 PDT
(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)
Comment 9 2022-04-19 12:29:21 PDT
Ryosuke Niwa
Comment 10 2022-04-19 20:12:10 PDT
We should fix https://bugs.webkit.org/show_bug.cgi?id=80159 before unprefixing this.
Ryosuke Niwa
Comment 11 2022-04-19 20:13:17 PDT
(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)
Comment 12 2022-04-20 00:33:33 PDT
Tim Nguyen (:ntim)
Comment 13 2022-04-20 00:37:31 PDT
Comment on attachment 457965 [details] Patch Just saw Ryosuke's comments
Tim Nguyen (:ntim)
Comment 14 2022-04-20 03:38:03 PDT
(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)
Comment 15 2022-04-20 03:39:56 PDT
Created attachment 457972 [details] [fast-cq] Patch
EWS
Comment 16 2022-04-20 03:44:48 PDT
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)
Comment 17 2022-04-20 08:41:33 PDT
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)
Comment 18 2022-04-21 03:00:44 PDT
(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
Comment 19 2022-06-25 13:22:07 PDT
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)
Comment 20 2022-06-25 13:29:58 PDT
(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
Comment 21 2022-06-25 13:38:01 PDT
(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;'>`.
Ahmad Saleem
Comment 23 2022-10-16 03:07:28 PDT
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!
Sam Sneddon [:gsnedders]
Comment 24 2024-10-29 09:49:12 PDT
Michał Gołębiowski-Owczarek
Comment 25 2024-12-07 09:00:05 PST
This issue is now the main blocker for jQuery removing the autoprefixing logic for its `.css()` API. I’d appreciate a fix!
Alexsander Borges Damaceno
Comment 26 2025-01-06 19:51:18 PST
Note You need to log in before you can comment on or make changes to this bug.