Closed runvnc closed 11 years ago
I don't think it's possible to tell apart an insertion triggered by dragging and dropping text from a simple clipboard insertion..
Im familiar with how it works so will takea look but it sounds like a browser bug
@ithkuil I tried but failed to replicate in chrome on linux mint chrome v25
http://beta.etherpad.org/p/HjaHbt1Sfs
What is your exact chrome version and what OS?
OK, thank you for trying. I reported this inaccurately it seems. I have just now been trying in Firefox on Windows. The first time I tried it, when I reloaded it had copied. The other times it did not copy.
So far my tests in Chrome/Chromium on Windows for all versions are doing it (copying instead of move, evident when you reload).
So it was not accurate to say Chrome 25 I think, its just that the users just noticed it. My users are just going to use control x and control v for now instead of dragging with the mouse.
Thanks for looking into it. I would say if you try a few more times on Windows you will probably see the problem but as long as users can get used to using control x control v instead of dragging and dropping, this might not be a high priority.
Yep, doing two drag and drops does a copy not a move. This makes the users experience completely broken. It appears to be a cross browser bug.
This bug appears to affect all Etherpad deployments including the old Etherpad. To replicate you have to drag 'n drop some content and over again creating new lines.
Not sure what's changed, but since the new Chrome 25 update, when you select some text and drag it to a different location in the file, it looks like it is moving it like it used to, but if you re-open the pad, it was actually copied.
If anyone has a guess as to which part of ace2_inner or which file to look at to try to come up with a workaround, I would really appreciate it.
Does it normally specifically detect a text move with a mouse drag? Not sure if I can find anything in the source that is doing that.