[Bug] Cut and paste with columns of text results in jumbled text at new location

[Harry-W-Haines-III]

After the latest update (version 1.12) when cutting and pasting columns of text the pasted results are jumbled. Removed the tabs and had the same results. Also affects lines that are highlighted and dragged to another position. Issue does not occur if I cut the text to Xed and then paste back into sticky.

W 0 PC Rick O Fallon, MO KK 4 TW Jim Clarksville, TN KE 4 TCT Dan Knoxville, TN

ends up as:

Dan     Knoxville, TN

TCT 4 KE Jim Clarksville, TN TW 4 KK, MO FallonW 0 PC Rick O

[Harry-W-Haines-III]

Has anyone else been able to reproduce this? Just copy and paste a few rows out of a spreadsheet into sticky notes. Then highlight and drag or cut/paste the contents into a different position in the note. This did not occur in sticky 1.11 but it was immediately noticeable in 1.12. I thought the computer was going nuts when it first happened as I use this app every morning. Used Xpad as a work around until I could block the upgrade from 1.11 in LM 21 and 1.8 in LMDE5.

[collinss]

I'm not sure what exactly your problem is without more clear steps to reproduce and a better description of how the observed behavior is different from what you expect. I tried copying from a spreadsheet, and it seemed to work just fine. Do keep in mind that it's inserting a tab in between data in adjacent cells, which could cause weird formatting if the line is long enough to wrap. I also have no idea what changed between versions that could have caused this behavior to change.

[Harry-W-Haines-III]

Okay I will try again how to reproduce it. Copy and paste 4-5 lines from a spreadsheet into sticky notes (does not have to be a spreadsheet) in this case a text file. Select one line of text or a block of lines in sticky notes and drag and drop it to a different row or cut and paste. See if the results become jumbled like the last screenshot. Even if I took the tabs out and just had columns of text with spaces, the result was the same. Using this as an example:

Original Note:

Highlight two lines and drag them to the an empty line:

And this is the result:

text-file-for-sticky-issue.txt This does not happen with Sticky 1.8 or 1.11. Lines moved (or cut and pasted) are not jumbled at their new location.

[Harry-W-Haines-III]

@collinss I believe the issue results when commas are used in the line of text. I did another test with no tabs or text pasted into sticky. Just text typed in. The issue did not repeat. As soon as I added commas the issue re-appeared. The issue is when lines are highlighted, dragged and dropped to another location, the text at the new location is jumbled. This also applies to highlighting, cutting and pasting.

Please see the screen shots below. Original note starting out. Selecting text to drag and drop to an empty line. The resulting jumbled text at the new location. Here is the result in Sticky 1.11:

[MhmdFVC]

Yeah I have the same issue. I'm not entirely sure what situations cause it to occur though, but it's very pervasive for me. It seems like if you create a fresh note, the issue doesn't occur, but at some point, lines of text get permanently screwed and become jumbled if you cut/copy from the same note and paste into it.

For example, I pasted the same line 5 times copied externally, then tried copying the line from the note itself and pasting it another 5 times, and it's still fine. But then I did a bit of editing of a line, and even after changing it back to the exact text it had before, I got the bottom results after attempting to copy and paste it. Again, not sure what exactly is going on, but I will say that using this rough method, I managed to easily reproduce it without commas as well.

This happens every time when I try to reorganize my tasks on my actual to-do lists, since I use this program for that. I've been pasting externally and then re-cutting and pasting as a workaround, but it's ridiculous.

[Harry-W-Haines-III]

Any more activity on this? I am pretty sure it is the application itself and not any associated libraries. If I hold back to 1.8 on LMDE 5 or 1.11 on LM 21 drag and drop works fine. As soon as it is updated to 1.12 drag and drop / paste and cut results in jumbled text. Please see the latest set of screen shots on duplicating the issue.

[collinss]

Sorry, I haven't had a chance to look into it yet. Life's been rather crazy for me lately. It's on my radar though, so it will happen at some point (hopefully before next release).

[Harry-W-Haines-III]

Any chance we'd see a fix before Linux Mint 21.1 Stable Release? I am unable to access the sticky 1.11 Debian Package to downgrade on Linux Mint 21.1 to work around this bug / feature change.

[Harry-W-Haines-III]

Following up on this. I have been able to determine the above issue is caused by the note_buffer.py file. Copying the file from 1.11 over 1.13 in /lib/sticky seems to have remedied the issue.

[collinss]

Glad you found a workaround! Unfortunately, life has been busier lately than I had hoped and I haven't had a chance to work on this yet. I might be able to get to it over the holidays, but I can't guarantee it will make it in the coming stable release.

[the0neWhoKnocks]

Automated @Harry-W-Haines-III's fix

  # Download working version
  wget https://github.com/linuxmint/sticky/archive/refs/tags/1.11.zip -O ~/Downloads/sticky-v1.11.zip
  # Stop sticky
  killall sticky.py
  # Back up bad file (just in case)
  sudo mv /lib/sticky/note_buffer.py /lib/sticky/note_buffer.py.bak
  # Patch with good file (requires `p7zip-full` to be installed)
  sudo 7z e ~/Downloads/sticky-1.11.zip sticky-1.11/usr/lib/sticky/note_buffer.py -o/lib/sticky/
  # Start sticky (NO_AT_BRIDGE used to ignore 'accessibility bus' warning)
  NO_AT_BRIDGE=1 gtk-launch sticky.desktop
  # Clean-up
  rm ~/Downloads/sticky-1.11.zip

[collinss]

I finally got a chance to play around with this and I'm completely unable to reproduce this issue. I've tried several of the examples you've provided, but everything seems to cut/copy/paste correctly. I'm beginning to wonder if this is some sort of os or hardware related bug. My best guess right now is that there's some sort of weird race condition or something, but I don't know what could cause it.

Could you all please post some basic information about your setup such as distribution, desktop environment, and maybe cpu and storage type (hdd/ssd/nvme). Perhaps there is some commonality that will give some insight into what's causing this issue.

[the0neWhoKnocks]

@collinss

Distro: Linux Mint 21 Vanessa base: Ubuntu 22.04 jammy
Kernel: 5.15.0-56-generic
Desktop: Xfce 4.16.0

CPU: 6-core model: Intel Core i7-8750H bits: 64 type: MT MCP arch: Coffee Lake rev: A
HD: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO Plus 1TB

Considering the architecture of your software, I think a more important question may be "what version of Python is installed"?

Python 3.10.6

[the0neWhoKnocks]

I reverted the patch, created a fresh note, and at first I couldn't reproduce. Then I went to an old note and looked at what I had in there, and the only difference that stood out was some formatted links. So I hit Enter after a link for it to format, then I cut and pasted it.

Also (another issue, but perhaps known), I noticed I can't use my mouse to select/highlight links. Place mouse cursor at the end of a formatted link, left-click to start selection, drag over link. No highlighting. If I continue to drag/highlight past the formatted link it starts to highlight. If I use my keyboard to highlight (as shown in the capture) it works as expected.

[collinss]

Ok, I can reproduce with that! Also reproduced the link highlight issue.

[collinss]

Turns out the issue was to do with internal formatting tags, which broke the pasted text into pieces in order to try to preserve formatting. The change I made that caused the issue included updating an internal placeholder for my own purposes that was used to keep track of where to paste the next piece of text, resulting in the jumbled placement. It was an easy enough fix once I figured out the problem, but was difficult to track down until I was able to reproduce it.

@the0neWhoKnocks I also fixed the link selection bug in 3140c112bf775ada3bdb0bc4ad974c131c752589. Thanks for bringing it to my attention!

[the0neWhoKnocks]

2-for-1 special, all bugs must go!

I'm glad you were able to triage and fix the issues so quickly.