Created attachment 178872 [details] Video demonstrating the clipped notification after a 0 msec notification SUMMARY Since Plasma 6.3.0, I realised one my shell scripts was causing buggy notification behaviour. In particular, the script sends a transient ("don't show in history") notification with a timeout of 0 to indicate a long-running action. In Plasma 6.2.x, the 0 msec timeout allowed normal priority notifications to appear indefinitely until dismissed, or if the script replaces it by ID: > NOTIFY_ID=$(notify-send -p -e -a Example -t 0 -i clock "Performing action...") > > notify-send -r ${NOTIFY_ID} -a Example -i emblem-success "Action completed" Currently, notifications in Plasma 6.3.1 now quickly fades in/out a notification sent with a 0 msec timeout. Sometimes, this also causes the next notification to appear clipped. I also observed the other day that one was incorrectly positioned in the top-left corner of the screen (BUG 499970 ?), but I was unable to reproduce that, so not sure if related. STEPS TO REPRODUCE 1. Execute "notify-send -a Test -i clock "This is a test" -t 0" 2. Observe how long the notification stays open. 3. Try executing again. The subsequent notification risks appearing clipped (regardless of timeout) OBSERVED RESULT (a) Notification quickly faded in and out. Can't read, too fast! (b) The next notification may appear clipped (only a few pixels visible) if the last one didn't fade/appear properly. EXPECTED RESULT (a) Notification with a 0 msec timeout are displayed indefinitely (OR fallback to a default timeout) (b) Notifications don't appear clipped. SOFTWARE/OS VERSIONS Arch Linux KDE Plasma: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 X11 ADDITIONAL INFORMATION It might be a user bug for sending a 0 msec timeout 'normal' notification, but on the other hand, it could be considered a Plasma 6.3 regression since 0 msec previously displayed such notification indefinitely. For now, the script can fix the problem by sending an "urgent" notification type, or set a very high timeout. Originally the bug report was for the clipping issue, but I'd guess it's due to the 0 timeout behaviour. Fixing the timeout might fix the clipping/position issues too. The video recording got lucky, since the first time the command ran, no notification was seen (no fade at all), then the next one was clipped. As later shown, it isn't always 100% reproducible.
I could reproduce this but the issue is that for some reason notify-send also sends CloseNotification on dbus. The following python code works fine in creating permanent notifications: import dbus def send_notification(summary, body, timeout): bus = dbus.SessionBus() # Connect to the session bus notify_service = bus.get_object("org.freedesktop.Notifications", "/org/freedesktop/Notifications") notify_interface = dbus.Interface(notify_service, "org.freedesktop.Notifications") app_name = "MyApp" replaces_id = 0 # 0 means no previous notification to replace icon = "" # No icon actions = [] # No actions hints = {} # No hints notify_interface.Notify(app_name, replaces_id, icon, summary, body, actions, hints, timeout) print("Notification sent successfully.") # Example usage send_notification("Hello!", "This is a test notification", timeout=0) Since this looks like an issue in notify-send, this would need to be reported to libnotify
Thank you for triaging! Can confirm under Plasma 6.2 that upgrading libnotify to 0.8.4-1 is the cause. Just a coincidence since Plasma updated around the same time! The clipping/cut off notifications may still be a bug on Plasma's side, were you able to reproduce that issue too?
(In reply to Luke Horwell from comment #2) > The clipping/cut off notifications may still be a bug on Plasma's side, were > you able to reproduce that issue too? Unfortunately I have been unable to reproduce that on my end (arch linux, master build, wayland) -- might be an x11-only issue, or maybe some more conditions need to be met to trigger the bug.