This is indeed chrome-specific. There are many issues in the chromium bug tracker mentioning user-select and clipboard, and I didn't want to go through all of them; this SO question is the only relevant thing that I could find, even if it doesn't have a solution.

From what I can see, chrome is correctly ignoring text with user-select:none for the plain text clipboard content, but not for the HTML content, which some editor might prefer over the plaintext one (you mentioned MS office, I've tested and confirmed this bug with LibreOffice Writer).

While it might be possible to emulate the correct behaviour via JavaScript, I wonder if it's worth the effort -- in particular, how common it is to copy diff text to a rich text editor.

As a reminder, the eventual plan is to rewrite diffs to use the CSS grid layout (T270775), which would most certainly overcome all the limitations of user-select. So perhaps we could just wait until our browser requirements are sufficiently high?

(CC'ing @MusikAnimal and @Samwilson for feedback)

While it might be possible to emulate the correct behaviour via JavaScript, I wonder if it's worth the effort -- in particular, how common it is to copy diff text to a rich text editor.

As a reminder, the eventual plan is to rewrite diffs to use the CSS grid layout (T270775), which would most certainly overcome all the limitations of user-select. So perhaps we could just wait until our browser requirements are sufficiently high?

If the effort is too great then yes, I wouldn't bother with fixing it unless we get complaints. I do not suspect a primary use-case for copying diffs is to paste into a rich text editor. Unfortunately use-cases weren't clearly outlined in the original wish, but the few that did mentioned "quoting diffs" – presumably in an on-wiki discussion, IRC or other communication venue, where you typically wouldn't want the table-like formatting seen in the diff. I would go even as far as to say we more often would not want the HTML to be copied at all, as wikitext diffs are sort of like diffs in version control software such as Git. In those cases it's about the code itself, and not the way the code is presented in the diff.

Either way we can still keep this open as it is very valid.

In T293898#7446371, @MusikAnimal wrote:

While it might be possible to emulate the correct behaviour via JavaScript, I wonder if it's worth the effort -- in particular, how common it is to copy diff text to a rich text editor.

As a reminder, the eventual plan is to rewrite diffs to use the CSS grid layout (T270775), which would most certainly overcome all the limitations of user-select. So perhaps we could just wait until our browser requirements are sufficiently high?

If the effort is too great then yes, I wouldn't bother with fixing it unless we get complaints.

Keeping the HTML format in the clipboard but without user-select:none elements seems hard -- we'd have to parse the HTML or something like that.

I would go even as far as to say we more often would not want the HTML to be copied at all, as wikitext diffs are sort of like diffs in version control software such as Git.

This would be easier; I just checked, and github also has something similar. Essentially, we would need to add a listener for the 'copy' event, prevent the default behaviour, and use event.clipboardData.setData( 'text/plain', our_text ).

Either way we can still keep this open as it is very valid.

Absolutely. My proposal is that we leave this open, but blocked on T270775 (which I'm not sure how soon will be actionable). If, for some reason, we decide that we don't want to copy the HTML anymore (e.g. because it's not useful, and many people copy diffs to rich text editors), then we can try the above to remove the HTML data from the clipboard.

We agreed that these browser-specific bugs won't be addressed in this phase. The CSS+JS solution provides basic support for copying from diffs, which is what we wanted to implement. Better support will come with T270775.