I noticed that sometimes text that I paste into a sticky note by middle-clicking on the desktop, gets lost after resuming a previous session, after suspending, rebooting, or booting after the battery has drained. The geometry of the sticky note is preserved, but its contents are empty. I currently use Plasma 6.4.4 on Wayland, packaged by KDE neon, but this bug has been around for a longer time period. At least one other user has experienced the same on Fedora 42 after rebooting: https://discuss.kde.org/t/text-in-sticky-notes-sometimes-gets-lost-after-resuming-session/40129
Just for the record, can you share more information of your system? System settings -> About this System -> Click "Copy details" and paste them here. Thanks!
Chnged type of bug
I managed to get this happen by doing following, but only once: 1. Have two activities 2. In second activity, add the widget 3. Type text in it 4. Right click desktop -> desktop and wallpaper -> change layout from folderview to desktop 5. This is where the text disappeared for me. Also the color of the note was changed to default. 6. Change it back 7. It's still gone However when I repeated the steps, it didn't happen again. Operating System: Fedora Linux 42 KDE Plasma Version: 6.5.80 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.16.8-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600
I haven't been able to reproduce this either after some testing. I do recall it happening at least once in the past, which is what prompted me to switch from a desktop-based sticky note to a panel-based sticky note, where it has never happened. We'll likely need to nail down a consistent set of steps to reproduce to do anything about it. Raising severity to critical since it results in data loss.
I have been able to reproduce this issue twice so far by creating one or more new notes (using a middle-click on the desktop) and then c to simulate a sudden power loss such as battery drainage. I have not been able to reproduce the issue by triggering suspend in the following ways: * Closing the laptop lid (but I am quite sure data loss occurred in this way in the past), * Selecting suspend manually from the system menu, * Sending a suspend signal directly without going through any DE daemons: echo mem | sudo tee /sys/power/state However, I suspect the outcome might be different if the system remains in suspend for a longer time instead of being resumed immediately. This leads me to believe the bug is related to data being cached or stored in memory without being written to disk. I also tested by running killall plasmashell, but the issue did not reproduce. This suggests that another process is responsible for holding the notes' content in memory. Additionally, I found that the contents of notes cannot be restored from ~/.local/share/plasma_notes/. This prompted me to investigate when they are actually written there for permanent storage. I set up a watch: notifywait -m -e create -e modify ~/.local/share/plasma_notes/ Setting up watches. Watches established. No events are triggered when creating a new note or when suspending the system through the DE menu. The newly created note is only saved once it is edited, for example by adding at least one more character. .local/share/plasma_notes/ CREATE 037b2cb7-1f28-460b-8cc8-75fa31512c .local/share/plasma_notes/ MODIFY 037b2cb7-1f28-460b-8cc8-75fa31512c .local/share/plasma_notes/ MODIFY 037b2cb7-1f28-460b-8cc8-75fa31512c Then the note also survives pressing Alt+SysRq+B. Here are some details about my setup as requested. Operating System: KDE neon User Edition KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 Kernel Version: 6.14.0-28-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-10510U CPU @ 1.80GHz Memory: 16 GiB of RAM (15.4 GiB usable) Graphics Processor 1: Intel® UHD Graphics Graphics Processor 2: Quadro P520 Manufacturer: HP Product Name: HP ZBook Firefly 14 G7 Mobile Workstation
To clarify on my previous message: I used the "Alt+SysRq+B" combination to simulate power loss.
Raising severity to critical again since this results in data loss.
(In reply to smihael from comment #5) > No events are triggered when creating a new note or when suspending the > system through the DE menu. The newly created note is only saved once it is > edited, for example by adding at least one more character. On my machine, it seems like it only saves the note once I interact with an element outside the note, or press the right mouse button.
I can confirm that; it only saves the content after focus loss. I think I can now confirm the original issue, too. When I create a note by middle-click pasting, no file is created in ~/.local/share/plasma_notes/. Only once I click into the note once and then click away from it to make it lose focus, *then* a file is created in ~/.local/share/plasma_notes/. I think we can fix this by using a timer to auto-save some number of seconds after the last edit, and activate the timer by default so the first time a note is created, it fires once even if you don't make any further edits.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/932
Git commit 8ceb43459a448bb56d1b3b22b746b1b7d7503d39 by Nate Graham. Committed on 30/10/2025 at 15:46. Pushed by ngraham into branch 'master'. applets/notes: save text more frequently Currently the text is saved only after the note widget is de-focused or destroyed gracefully. This results in a few situations where the text (which is critically important) won't be saved. Two examples: - Middle-click-paste on the desktop to create a note, but never click in it to focus it - Run out of power or have Plasma crash while you had a note focused with unsaved text To fix this, always save the text 10 seconds after it was last changed. FIXED-IN: 6.4.6 M +15 -0 applets/notes/package/contents/ui/main.qml https://invent.kde.org/plasma/kdeplasma-addons/-/commit/8ceb43459a448bb56d1b3b22b746b1b7d7503d39
Git commit 41ec5c9297cfc4b2272e90f14efc3c16623a5bcc by Nate Graham. Committed on 30/10/2025 at 15:47. Pushed by ngraham into branch 'Plasma/6.5'. applets/notes: save text more frequently Currently the text is saved only after the note widget is de-focused or destroyed gracefully. This results in a few situations where the text (which is critically important) won't be saved. Two examples: - Middle-click-paste on the desktop to create a note, but never click in it to focus it - Run out of power or have Plasma crash while you had a note focused with unsaved text To fix this, always save the text 10 seconds after it was last changed. FIXED-IN: 6.4.6 (cherry picked from commit 8ceb43459a448bb56d1b3b22b746b1b7d7503d39) 239bba66 applets/notes: save text more frequently Co-authored-by: Nate Graham <nate@kde.org> M +15 -0 applets/notes/package/contents/ui/main.qml https://invent.kde.org/plasma/kdeplasma-addons/-/commit/41ec5c9297cfc4b2272e90f14efc3c16623a5bcc
Git commit ec53c9a95d333cedfeba2bbf9c9ab42608e1bf55 by Nate Graham. Committed on 30/10/2025 at 15:48. Pushed by ngraham into branch 'Plasma/6.4'. applets/notes: save text more frequently Currently the text is saved only after the note widget is de-focused or destroyed gracefully. This results in a few situations where the text (which is critically important) won't be saved. Two examples: - Middle-click-paste on the desktop to create a note, but never click in it to focus it - Run out of power or have Plasma crash while you had a note focused with unsaved text To fix this, always save the text 10 seconds after it was last changed. FIXED-IN: 6.4.6 (cherry picked from commit 8ceb43459a448bb56d1b3b22b746b1b7d7503d39) 239bba66 applets/notes: save text more frequently Co-authored-by: Nate Graham <nate@kde.org> M +15 -0 applets/notes/package/contents/ui/main.qml https://invent.kde.org/plasma/kdeplasma-addons/-/commit/ec53c9a95d333cedfeba2bbf9c9ab42608e1bf55