Bug 510087

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