Page MenuHomePhabricator

Safari copies both sides of the diff
Open, Needs TriagePublicBUG REPORT

Description

What is the problem?

On Safari, trying to copy one side of the diff actually copies both, even though it shows that only one side is selected. See screenshot.

This bug was originally found by @imaigwilo.

Steps to reproduce problem
  1. Open Safari
  2. Go to https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Wikidiff2_new_page&type=revision&diff=511452&oldid=511451
  3. Select one side of the diff (either left or right) and copy
  4. Open a text editor (for example) and paste

Expected behavior: Only the content from the one side of the diff you selected in step 3 is copied
Observed behavior: Both sides are copied

Environment

Browser Safari 14 (Big Sur), Safari 13 (Catalina)
Wiki(s): https://en.wikipedia.beta.wmflabs.org MediaWiki 1.38.0-alpha (ad94e00) 06:01, 22 October 2021.

Screenshots (if applicable):

safari_copy_both_sides_bug.png (500×1 px, 43 KB)

Event Timeline

I've fiddled with this for a while. One possibility is that we add a handler for the copy event, and override the clipboard content with what we actually want to be copied. Browser support for changing clipboard data from a copy event is not perfect (ref), but it's still decent and it would mitigate the issue on Safari. Doing this would also fix T293898.

The real challenge is to get the actual text that we want to be copied. One way of doing that is document.getSelection().toString(), but this doesn't even work on chrome (where the plaintext clipboard content is correct): it includes text from unselectable elements. Which means we would need to parse the selected HTML, filter out unwanted comment, and then concatenate it in a way that makes sense. This might be hard to get right, especially if we account for selections that include text from both inside and outside the diff table.

Or we could acknowledge this as a known limitation that will eventually be resolved with T270775.

Or we could acknowledge this as a known limitation that will eventually be resolved with T270775.

I am aligned with this thinking. We should acknowledge the limitation with the knowledge that it will eventually be mitigated by T270775. It should still be better than previous behavior in the meantime.