by using e.g. user-select: none;
|Open||None||T139601 Better solutions to edit conflicts (#1)|
|Resolved||Tobi_WMDE_SW||T143824 Show text changes of both parties in edit conflict text field|
|Resolved||WMDE-Fisch||T151332 Make header texts in diff view non-copyable|
- Mentioned In
- rESCC43a776243596: Used pseudo elements to prevent copying
rESCC17d5be0aac4d: Implemented feedback regarding pseudo elements to prevent copying
rESCCd7affcc8f7eb: Used pseudo elements to prevent copying
rESCC238081647269: Used pseudo elements to prevent copying
rESCC62b376dcb1ab: Make header texts in diff view non-copyable
The patch merged prevents users from selecting the header text directly. And when the text can't be selected it also can't be copied - in theory.
But if you select the selectable text before a header and drag the selection it to text underneath the header, the text in between will also be selected and therefore can also be copied. ( see screenshot ). Firefox seems to be the only browser that does not select the text in that case.
So you still could copy the text. This could be fixed by using CSS pseudo elements to display the text . Then the text really can't be selected or copied. The only concern there would be accessibility. Although most modern browsers and screen readers seem to be able deal with that nowadays there are still exceptions .
So last option some JS magic? Or keep it like it is now?
We might actually *want* the headline in there, which is, if the user copies mine and their version. Having an indicator where which block starts makes sense.
If you look at the way git does it, I wonder if it would not be cool to have something like "-----MINE------" copied (but thats just an idea)
Where it is annoying, I assume, if you want to copy a part of an unchanged block and want to take the their block along. On the other hand, you may want to copy the mine, and no matter what we do with the headlines, we will always have the their block with it (because it comes before mine.
- I assume the current way it not so bad.
- It is complicated, and it seems that making headlines unselectable does not resolve the problem of having text which we don't want.
I've played around a bit with this and like @WMDE-Fisch said, it seems that the user-select attribute is still quite buggy in some browsers. It works in Gecko as expected, but in WebKit you can accidentally select non-selectable text by selecting elements around that text. A nice example can be found here.
So, I'm wondering whether we're confusing users more by introducing this feature. E.g. in Chrome the text looks like it is not selected, but it gets copied which feels weird.
I would go for CSS pseudo elements or abandon the feature completely.
or abandon the feature completely.
No strong objection. Without testing we do not know anyway.
I wonder if we should document this open problem and ask users about it when we are in beta (explicitly asking for behavior, like "Does this [unwanted selecting] happen to you?")