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
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).
(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.
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?
<rdar://problem/86127924>
Created attachment 457923 [details] Patch
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?
Created attachment 457928 [details] Patch
(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.
Created attachment 457929 [details] Patch
We should fix https://bugs.webkit.org/show_bug.cgi?id=80159 before unprefixing this.
(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.
Created attachment 457965 [details] Patch
Comment on attachment 457965 [details] Patch Just saw Ryosuke's comments
(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.
Created attachment 457972 [details] [fast-cq] Patch
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].
It seems unfortunate to unprefix this while keeping it as an inherited property instead of doing what the spec says (and Firefox does)?
(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
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).
(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.
(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;'>`.
Reverted by https://github.com/WebKit/WebKit/commit/e4b63beaeb743e2d311d689590ec49bb0728b3ff
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!