Bug 80159

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.

> 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.

*** Bug 90348 has been marked as a duplicate of this bug. ***

(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.

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

(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

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.

(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.

(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).

> * 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).

(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.

(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. :)

<rdar://problem/13689646>

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

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?

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."

(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!

Chrome returns the one range (like WebKit) for getSelection() as well, and getSelection().toString() is "one two three" like WebKit. Gecko returns "one three"...

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.

Created attachment 463953 [details] Test case Based on this test case, Chrome includes the content with -webkit-user-select: none in the clipboard content.

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.

Pull request: https://github.com/WebKit/WebKit/pull/7467

Committed 257749@main (166aef896770): <https://commits.webkit.org/257749@main> Reviewed commits have been landed. Closing PR #7467 and removing active labels.