80159 2012-03-02 06:55:12 -0800 Content with -webkit-user-select: none should be skipped during copy 2022-12-12 11:41:04 -0800 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED BrowserCompat, InRadar P2 Normal --- 208677 128236 216325 1 ultr rniwa 234234234x24dfgdfg aandrey aidan.feldman benjaminkindle bn clopez cory cpeterson desamo dougalg ehsan enrica eoconnor laughinghan ntim rniwa sanjaylgb shanestephens shezbaig.wk simon.fraser tellowkrinkle oldest_to_newest 569630 0 129896 ultr 2012-03-02 06:55:12 -0800 Created attachment 129896 testcase "-webkit-user-select:none" CSS property is not respected when copying content. Testcase: <span>one</span> <span style="-webkit-user-select:none; -moz-user-select:none;">two</span> <span>three</span> When you select the above text and copy it, your clipboard will contain "one two three" instead of "one three". It works OK in Mozilla Firefox - only elements with no -webkit-user-select:none set are copied. 584942 1 shanestephens 2012-03-21 20:54:33 -0700 Firefox has the same behavior, and even documents this ( https://developer.mozilla.org/en/CSS/user-select). In the absence of an explicit specification suggesting the correct behavior is to respect the property when copying content, this doesn't seem to be a bug. 634641 2 ultr 2012-05-26 03:52:23 -0700 > Firefox has the same behavior This is not true. I have just tested it and it does NOT copy -moz-user-select:none fragments into the clipboard. Tested on: - Iceweasel 10.0.4 on Debian - Firefox 12.0 on Windows (there seems to be a bug: -moz-user-select:none fragment can be selected, but it is still NOT copied into the clipboard) There should at least be an option to change this behavior in Qt Webkit, so that this feature can be used in programs. 661144 3 ap 2012-07-01 10:57:57 -0700 *** Bug 90348 has been marked as a duplicate of this bug. *** 661634 4 rniwa 2012-07-02 11:27:51 -0700 (In reply to comment #1) > Firefox has the same behavior, and even documents this ( https://developer.mozilla.org/en/CSS/user-select). In the absence of an explicit specification suggesting the correct behavior is to respect the property when copying content, this doesn't seem to be a bug. This is not true at all. 808331 5 234234234x24dfgdfg 2013-01-16 06:23:03 -0800 My system does not copy the text which is effected by "-webkit-user-select:none", too. Tested with Chrome 24.0.1312.52, Firefox 16.0.1 & WebKit r139829 on Mac OS 808334 6 234234234x24dfgdfg 2013-01-16 06:26:04 -0800 (In reply to comment #5) > My system does not copy the text which is effected by "-webkit-user-select:none", too. Tested with Chrome 24.0.1312.52, Firefox 16.0.1 & WebKit r139829 on Mac OS Sorry I wanted to say it DOES COPY 810068 7 cpeterson 2013-01-17 18:31:49 -0800 Two interesting differences between -webkit-user-select:none and -moz-user-select:none (and the related -moz-user-select:-moz-none) is the highlighting and copying of text: * WebKit: CMD+A (or dragging a selection) will highlight the text surrounding a `none` span, but NOT the `none` text. * Gecko: CMD+A (or dragging a selection) will highlight all text, INCLUDING the `none` text. * WebKit: CMD+C will copy all text, INCLUDING the `none` text. * Gecko: CMD+C will copy the text surrounding a `none` span, but NOT the `none` text. 810914 8 rniwa 2013-01-18 12:11:14 -0800 (In reply to comment #7) > Two interesting differences between -webkit-user-select:none and -moz-user-select:none (and the related -moz-user-select:-moz-none) is the highlighting and copying of text: > > * WebKit: CMD+A (or dragging a selection) will highlight the text surrounding a `none` span, but NOT the `none` text. > * Gecko: CMD+A (or dragging a selection) will highlight all text, INCLUDING the `none` text. Gecko's behavior is counter-intuitive here. Isn't the whole point of user-select: none so that the text is never selected/highlighted? > * WebKit: CMD+C will copy all text, INCLUDING the `none` text. > * Gecko: CMD+C will copy the text surrounding a `none` span, but NOT the `none` text. Gecko's behavior makes sense here. I previously said that I'm afraid there might be a compat. issue but I think it makes sense to match Gecko's behavior on the basis that the user wouldn't expect unhighlighted text to be included when they hit cmd/ctl+c. 810945 9 cpeterson 2013-01-18 12:47:40 -0800 (In reply to comment #8) > > * WebKit: CMD+A (or dragging a selection) will highlight the text surrounding a `none` span, but NOT the `none` text. > > * Gecko: CMD+A (or dragging a selection) will highlight all text, INCLUDING the `none` text. > > Gecko's behavior is counter-intuitive here. Isn't the whole point of user-select: none so that the text is never selected/highlighted? I agree; I feel that highlighting text that is not going to copied is misleading. > > * WebKit: CMD+C will copy all text, INCLUDING the `none` text. > > * Gecko: CMD+C will copy the text surrounding a `none` span, but NOT the `none` text. > > Gecko's behavior makes sense here. I previously said that I'm afraid there might be a compat. issue but I think it makes sense to match Gecko's behavior on the basis that the user wouldn't expect unhighlighted text to be included when they hit cmd/ctl+c. I think part of the confusion is whether -*-user-select:none (which is not standard CSS) intends "selection" to means text highlight or copying. I think the user-select:none use case is to prevent users from highlighting and copying elements of a web page that are "not content", such as header or footer text. Unfortunately, I can imagine news websites marking their articles' text as user-select:none as weak "copy protection" (like websites that use JS to prevent right-clicking on images). 810977 10 ultr 2013-01-18 13:28:10 -0800 > * Gecko: CMD+A (or dragging a selection) will highlight all text, INCLUDING the `none` text. That was working fine (-moz-user-select:none text was not highlighted nor copied) in Mozilla Firefox when I submitted this bug. But I confirm this is broken now (Iceweasel 18.0). 810981 11 rniwa 2013-01-18 13:32:45 -0800 (In reply to comment #9) > > > * WebKit: CMD+C will copy all text, INCLUDING the `none` text. > > > * Gecko: CMD+C will copy the text surrounding a `none` span, but NOT the `none` text. > > > > Gecko's behavior makes sense here. I previously said that I'm afraid there might be a compat. issue but I think it makes sense to match Gecko's behavior on the basis that the user wouldn't expect unhighlighted text to be included when they hit cmd/ctl+c. > > I think part of the confusion is whether -*-user-select:none (which is not standard CSS) intends "selection" to means text highlight or copying. I think the user-select:none use case is to prevent users from highlighting and copying elements of a web page that are "not content", such as header or footer text. Unfortunately, I can imagine news websites marking their articles' text as user-select:none as weak "copy protection" (like websites that use JS to prevent right-clicking on images). Yeah, that'll be very annoying for users. 811034 12 cpeterson 2013-01-18 14:17:51 -0800 (In reply to comment #10) > That was working fine (-moz-user-select:none text was not highlighted nor copied) in Mozilla Firefox when I submitted this bug. But I confirm this is broken now (Iceweasel 18.0). ultr, in comment #2, you said that I that Iceweasel 10 on Debian did NOT highlight the "none" text, but Firefox 12 on Windows did. I just tested Firefox 10 and 12 on Mac OS X. Firefox 12 does highlight the "none" text, but Firefox 10 does NOT! So the text highlight bug is a Gecko regression in Firefox 11 or 12. Thanks for pointing this regression. I'm going to file a Firefox bug now. :) 878165 13 desamo 2013-04-18 18:06:54 -0700 <rdar://problem/13689646> 1058423 14 laughinghan 2015-01-02 08:44:15 -0800 FYI Firefox's misleading behavior of highlighting text that is not going to copied has been fixed in Firefox 35 (currently in beta): https://bugzilla.mozilla.org/show_bug.cgi?id=739396 So -moz-user-select:none is pretty much perfect now in Firefox. Also, just to link this stuff together, the corresponding Chromium issue: https://code.google.com/p/chromium/issues/detail?id=147490 1555864 15 cory 2019-07-25 11:54:50 -0700 I'm seeing this working as expected in Chrome, Firefox and Edge. Is there any hope this might get fixed for Safari at some point? 1622906 16 dougalg 2020-02-25 22:03:43 -0800 It would be nice for this to be consistent across all browsers. It is even mentioned in the spec now: https://drafts.csswg.org/css-ui-4/#content-selection "UAs are encouraged to keep the visual selection consistent with what would get copied to the clipboard when copying. Copying text that does not appear to be selected, or vice versa, is highly confusing to users." 1862855 17 ntim 2022-04-20 01:28:57 -0700 getSelection() seems to return the correct selection without the user-select: none content. Not sure what the manual copy process uses, but it should use something similar. 1862865 18 ntim 2022-04-20 02:20:07 -0700 (In reply to Tim Nguyen (:ntim) from comment #17) > getSelection() seems to return the correct selection without the > user-select: none content. Not sure what the manual copy process uses, but > it should use something similar. I stand corrected, getSelection() is wrong, it returns one range instead of two! 1862866 19 ntim 2022-04-20 02:22:45 -0700 Chrome returns the one range (like WebKit) for getSelection() as well, and getSelection().toString() is "one two three" like WebKit. Gecko returns "one three"... 1862966 20 rniwa 2022-04-20 09:53:39 -0700 WebKit doesn't support multi-range selection. We need to adjust the behavior of StyledMarkupAccumulator in Markup.cpp. We probably also need to add a mode of TextIterator which skips content with this style applied as well, and use that in copy operation. 1917851 21 463953 rniwa 2022-12-08 21:17:11 -0800 Created attachment 463953 Test case Based on this test case, Chrome includes the content with -webkit-user-select: none in the clipboard content. 1918206 22 tellowkrinkle 2022-12-10 12:45:49 -0800 It seems to only include it in the html clipboard content, if you paste with "paste and match formatting" (shift-cmd-option-v) it pastes without the unselectable text. This happens to match my specific use case (marking <rp> and <rt> tags as unselectable), where I would want the tags copied in html but not in plain text, but I don't think that's what user-select was really meant for. 1918388 23 rniwa 2022-12-11 23:21:24 -0800 Pull request: https://github.com/WebKit/WebKit/pull/7467 1918559 24 ews-feeder 2022-12-12 11:40:58 -0800 Committed 257749@main (166aef896770): <https://commits.webkit.org/257749@main> Reviewed commits have been landed. Closing PR #7467 and removing active labels. 129896 2012-03-02 06:55:12 -0800 2012-03-02 06:55:12 -0800 testcase webkit-user-select-copying.html text/html 376 ultr PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEvL0VOIiAiaHR0cDov L3d3dy53My5vcmcvVFIvaHRtbDQvc3RyaWN0LmR0ZCI+CjxodG1sPgo8aGVhZD4KICA8dGl0bGU+ Y29weWluZyB3aXRoIC13ZWJraXQtdXNlci1zZWxlY3Q6bm9uZTwvdGl0bGU+CiAgPG1ldGEgaHR0 cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7Y2hhcnNldD1VVEYtOCIg Lz4KPC9oZWFkPgo8Ym9keT4KCgo8c3Bhbj5vbmU8L3NwYW4+CjxzcGFuIHN0eWxlPSItd2Via2l0 LXVzZXItc2VsZWN0Om5vbmU7IC1tb3otdXNlci1zZWxlY3Q6bm9uZTsiPnR3bzwvc3Bhbj4KPHNw YW4+dGhyZWU8L3NwYW4+CgoKPC9ib2R5Pgo8L2h0bWw+Cg== 463953 2022-12-08 21:17:11 -0800 2022-12-08 21:17:11 -0800 Test case copy-with-user-select-none.html text/html 1514 rniwa PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8Ym9keT4KPGJ1dHRvbiBpZD0iYnV0dG9uIiBvbmNsaWNr PSJjb3B5KCkiPkNvcHk8L2J1dHRvbj4KPGRpdiBpZD0iY29udGVudCI+aGVsbG8gPHNwYW4gc3R5 bGU9InVzZXItc2VsZWN0OiBub25lOyAtd2Via2l0LXVzZXItc2VsZWN0OiBub25lOyAtbW96LXVz ZXItc2VsZWN0OiBub25lOyI+d29ybGQgPC9zcGFuPjxzcGFuIGluZXJ0PmZvbyA8L3NwYW4+YmFy PC9kaXY+CjxkaXYgaWQ9ImRlc3RpbmF0aW9uIiBvbnBhc3RlPSJwYXN0ZShldmVudCkiIGNvbnRl bnRlZGl0YWJsZT5QYXN0ZSBoZXJlPC9kaXY+CjxzY3JpcHQgc3JjPSIuLi8uLi9yZXNvdXJjZXMv anMtdGVzdC5qcyI+PC9zY3JpcHQ+CjxzY3JpcHQ+CgpkZXNjcmlwdGlvbihgVGhpcyB0ZXN0cyBj b3B5aW5nIHRleHQgd2l0aCAtd2Via2l0LXVzZXItc2VsZWN0OiBub25lLiBXZWJLaXQgc2hvdWxk IG5vdCBjb3B5IHRleHQgd2l0aCAtd2Via2l0LXVzZXItc2VsZWN0OiBub25lLjxicj4KVG8gbWFu dWFsbHkgdGVzdCwgY2xpY2sgdGhlIGJ1dHRvbiBiZWxvdyBhbmQgdGhlbiBwYXN0ZS5gKTsKCmpz VGVzdElzQXN5bmMgPSB0cnVlOwoKZnVuY3Rpb24gY29weSgpIHsKICAgIGdldFNlbGVjdGlvbigp LnNlbGVjdEFsbENoaWxkcmVuKGNvbnRlbnQpOwogICAgc2hvdWxkQmVUcnVlKCdnZXRTZWxlY3Rp b24oKS50b1N0cmluZygpLmluY2x1ZGVzKCJoZWxsbyIpJyk7CiAgICBzaG91bGRCZUZhbHNlKCdn ZXRTZWxlY3Rpb24oKS50b1N0cmluZygpLmluY2x1ZGVzKCJ3b3JsZCIpJyk7CiAgICBzaG91bGRC ZUZhbHNlKCdnZXRTZWxlY3Rpb24oKS50b1N0cmluZygpLmluY2x1ZGVzKCJmb28iKScpOwogICAg c2hvdWxkQmVUcnVlKCdnZXRTZWxlY3Rpb24oKS50b1N0cmluZygpLmluY2x1ZGVzKCJiYXIiKScp OwogICAgZG9jdW1lbnQuZXhlY0NvbW1hbmQoJ2NvcHknLCBmYWxzZSwgbnVsbCk7CiAgICBkZXN0 aW5hdGlvbi5mb2N1cygpOwogICAgZG9jdW1lbnQuZXhlY0NvbW1hbmQoJ3NlbGVjdEFsbCcsIGZh bHNlLCBudWxsKTsKfQoKZnVuY3Rpb24gcGFzdGUoZXZlbnQpIHsKICAgIHNldFRpbWVvdXQoKCkg PT4gewogICAgICAgIHNob3VsZEJlVHJ1ZSgnZGVzdGluYXRpb24udGV4dENvbnRlbnQuaW5jbHVk ZXMoImhlbGxvIiknKTsKICAgICAgICBzaG91bGRCZUZhbHNlKCdkZXN0aW5hdGlvbi50ZXh0Q29u dGVudC5pbmNsdWRlcygid29ybGQiKScpOwogICAgICAgIHNob3VsZEJlRmFsc2UoJ2Rlc3RpbmF0 aW9uLnRleHRDb250ZW50LmluY2x1ZGVzKCJmb28iKScpOwogICAgICAgIHNob3VsZEJlVHJ1ZSgn ZGVzdGluYXRpb24udGV4dENvbnRlbnQuaW5jbHVkZXMoImJhciIpJyk7CiAgICAgICAgZmluaXNo SlNUZXN0KCk7CiAgICB9LCAwKTsKfQoKaWYgKHdpbmRvdy50ZXN0UnVubmVyKSB7CiAgICBidXR0 b24uY2xpY2soKTsKICAgIGRvY3VtZW50LmV4ZWNDb21tYW5kKCdwYXN0ZScsIGZhbHNlLCBudWxs KTsKfQoKPC9zY3JpcHQ+CjwvYm9keT4KPC9odG1sPgo=