GSConnect notifications endlessly re-notify on GNOME 46/Ubuntu 24.04

[BloodyIron]

Describe the bug

I recently upgraded from Ubuntu 23.10 to 24.04, and this moved me to GNOME 46 (I think I was on 45, not sure). And as a result, notifications from GSConnect on the desktop just keep renotifying non-stop until I dismiss them (which I don't want to do, as that clears the notification on the phone too, which I don't want until I handle the notification).

Previously (before the upgrade and GNOME version change) I would get notified once per GSConnect notification thing (like, per E-Mail) and it would be hidden in the notification tray thinggy in Gnome. And that is exactly what I wanted.

Now, however, every, single, GSConnect notification, re-notifies after some period of time I haven't measured in the realm of 1-2 minutes or so. And when I get a lot of notifications from my phone that I want to handle LATER this turns into a lot of spam on my desktop I don't want.

Steps to reproduce

I believe I've already described how to reproduce this.

Expected behavior

I believe I've already answered this.

GSConnect version

57

Installed from

GNOME Extensions website

GNOME Shell version

46

Linux distribution/release

Ubuntu Desktop 24.04

Paired device(s)

Samsung Galaxy XCover6 Pro

KDE Connect app version

1.32.0

Plugin(s)

Notifications

Support log

No response

Screenshots

No response

Notes

I really think this is somehow tied to GNOME 46 as this behaviour change did not happen to me in the past.

[michas79de]

Same for me, upgraded yesterday from Ubuntu 22 to 24 and since then the notification spam started.

GSConnect version
57

GNOME Shell version
46

Linux distribution/release
Ubuntu 24.04.1 LTS

Paired device(s)
Fairphone 5

KDE Connect app version
1.32.0

[ferdnyc]

I really think this is somehow tied to GNOME 46 as this behaviour change did not happen to me in the past.

That's almost certainly true, as GNOME 46 involved a major overhaul to the entire notification system.

GNOME 46 brought persistent notifications that can now be interacted with in the notification list, which is extremely awesome. (If you miss your chance to hit a button in the popup notification, instead of that button disappearing forever now you can just open the list and expand the notification.)

But some things were also lost in the transition.

• The ability to including interactive widgets in a notification was removed, which broke the ability to type and send a Reply directly from a messaging notification.
• And I think our ability to have our notifications treated as Shell notifications probably broke, which has led to the issue reported here.

GSConnect has long contained code (in shell/notification.js) that uses the GNOME Shell private notification API to do things that aren't supported by the public API. It's likely the GNOME 46 changes broke that code, and left us falling back to the baseline Gio.Notification API.

The fallback API is very bare-bones. It involves creating instances of Gio.Notification and using GApplication calls to manage them, of which there are only two: g_application_send_notification and g_application_withdraw_notification. That's it.

g_application_send_notification supports updating an existing notification with new information. But unlike in the GNOME Shell notification API, where notifications can be silently updated, in calls to g_application_send_notification:

If a previous notification was sent with the same id, it will be replaced with notification and shown again as if it was a new notification.

And, GSConnect re-delivers notifications with the same id a LOT.

• Partly because it can't be sure whether it already sent a particular notification (it doesn't keep that info, and anyway it may have been restarted and lost it).
• Partly because it can't be sure the Shell is still showing the notification in question. (There are no API calls to ask it; notification data is only exposed in one direction.)
• Partly because the repeat could be an update with new information, so it re-sends it to ensure that the notification being displayed is as current as possible.
• And partly, I think, simply because in the past, it could do so silently.

But with our private API access to the notification system broken, notification resends are no longer silent, and they've instead become extremely intrusive.

[michas79de]

Thanks a lot for this explanation! (although it doesn't help much ATM ;-) )
I understand why there are so many re-deliveries.
Does this mean we have to wait for a fix in GNOME 46 or later, or is there a plan B to change the delivery behavior or something else?

[BloodyIron]

Awww I really liked being able to reply in GSConnect notifications! I really hope we get that back. Also, I too would like to hear about what the next steps look like. Thanks for the fleshing out of that @ferdnyc ! GSConnect helps me soooooo much and I really have no alternative, so I'm hoping a solution can be found/developed in a timely fashion (by whomever is to reasonably handle that).

[ferdnyc]

So, turns out this was not as complex as I feared, and did come down to a bug in our private-API notification handling. With the GNOME 46 changes, that code got rewritten to follow the GNOME Shell code, which does redisplay notifications every time they're updated (the same way it's documented to above).

But we don't want that, since we know we'll be getting a lot of repeat notifications. So I adjusted the code to only re-display notifications if the content has changed since the last update. Completely identical notifications won't trigger a redisplay.

@BloodyIron, @michas79de, or anyone else who wants to test the change can download the build artifact from PR #1860 to test it out. It seems to work correctly for me, but I don't have a whole lot of notifications getting sent back from my phone to my desktop, and it could really use some wider testing.

The build artifact is currently at this link: https://github.com/GSConnect/gnome-shell-extension-gsconnect/actions/runs/10804959879/artifacts/1917639591

That might change if it gets rebuilt for any reason, though.

[ferdnyc]

That might change if it gets rebuilt for any reason, though.

It already was, so yeah... the best way to make sure you're getting the updated artifact is to go to the PR (#1860), click on the "Checks" subtab, then click "CI" in the left-hand sidebar. You'll see the artifact (named [email protected]) down at the bottom of the page.

[ferdnyc]

(Help wanted not for the code itself, but for testing of the changes. The build artifact in #1860 can be installed by anyone interested in testing the fix.)

[michas79de]

Currently I'm not at home, but I would like to test it back at home in a few days.

[BloodyIron]

(Help wanted not for the code itself, but for testing of the changes. The build artifact in #1860 can be installed by anyone interested in testing the fix.)

Hey @ferdnyc sorry life stuff keeping me busy lately.

I just want to clarify so that I test "correctly". In this case, is testing as simple as downloading the content, putting it into the appropriate folder (for the plugin under gnome extensions installed folder for the user), and then observing results? Or is there anything more involved along the lines of compiling? I'm hoping no compiling is needed for me to test as I really want to avoid installing build kit onto this particular computer.

(oh and making sure the "old" version of the extension is deleted/moved-aside)

[ferdnyc]

@BloodyIron Sorry for the delay in getting back to you.

I just want to clarify so that I test "correctly". In this case, is testing as simple as downloading the content, putting it into the appropriate folder (for the plugin under gnome extensions installed folder for the user), and then observing results?

Pretty much, yes. When you download the latest build artifact, it'll come in the form of a .zip file named [email protected]. You can follow the "Install from zip" wiki instructions to install it in GNOME Shell.

Then, assuming you had a previous version installed, it's just a matter of logging out and back in again to restart the extension. (Not strictly necessary if GSConnect was not previously installed during your current session. But still not a terrible idea even then, just to be safe.)

Then you'd just use your system normally, and take note of the fact that forwarded notifications aren't constantly reappearing anymore. (But still do pop back up when then should, like when an SMS conversation has an additional message appended to it.)

[ferdnyc]

And since I've just fired off another build, anyone looking to test should wait until that finishes (by the time you read this it'll already be done), then grab the updated artifact which will also now contain the "Generate Support Log" fix from #1865.

[michas79de]

In the meantime the App was updated and I'm now with:

GSConnect version
57

GNOME Shell version
46

Linux distribution/release
Ubuntu 24.04.1 LTS

Paired device(s)
Fairphone 5

KDE Connect app version
1.32.0 -> 1.32.2

After a few days without annoying notifications, the problem was occurring again today.

Now I downloaded the artifact and installed it via gnome-extensions install --force [email protected], which (hopefully) was executed immediately without delay or feedback, but also without error message.

After logout/login, the notifications reappeared once - as they should - without re-notification for a few minutes until now.
I'll keep an eye on it, leave the tab open and report back at some point. Feel free to ask me anytime!

Full of hope, thank you for your quick response and effort!

Update:
5 hours later, the same notifications that popped up repeatedly before are not popping up again.
An SMS notification only appeared once on arrival and a second time hours later when a second SMS arrived from the same sender and the notification was updated/replaced.
So it seems to be working fine.
Again: I'll keep an eye on it, leave the tab open and report back at some point. Feel free to ask me anytime!

[ferdnyc]

5 hours later, the same notifications that popped up repeatedly before are not popping up again.
An SMS notification only appeared once on arrival and a second time hours later when a second SMS arrived from the same sender and the notification was updated/replaced.
So it seems to be working fine.
Again: I'll keep an eye on it, leave the tab open and report back at some point. Feel free to ask me anytime!

That all matches my experience with these changes, so I think it's looking good. Thanks for testing!

[BloodyIron]

I only today got around to installing the build artefact (from here : https://github.com/GSConnect/gnome-shell-extension-gsconnect/actions/runs/10917285744/artifacts/1946403454 ). And so far I think it's done the trick for reigning in the notifications to only show once!

I've only been testing it for a few hours, but so far it LOOKS to be working reliably. Yay!

Seriously though, thanks for those that made this happen! And I'm sorry that it took so long for me to come back and actually try it :( Life stuff jumped out in my face like it wanted to get hit by a bus or something. So thanks also to those who were interested in my testing feedback earlier!

Also without the artefact link in an earlier comment, I would not have really known where to find that payload since it wasn't a "release" ;P So thanks for linking to that too!

[ferdnyc]

@BloodyIron (et al), v58 is now released with these changes, and published to the GNOME extensions site. So, your installation should update automatically via the usual process.

[ferdnyc]

I have noticed the occasional weirdness with mirrored notifications, particularly when one occasionally gets delayed for... all of the various reasons that can happen, given the transient nature of the KDE Connect protocol connection.

For instance, I've had GSConnect mute/pause my media player in response to an incoming call notification... for a phone call that happened half an hour previous.

We may need to consider adding some timestamp checking, in the plugins that react to notifications. (Assuming the timestamps in older notifications will actually show that they're out of date.) If a notification is older than a few... well, seconds, actually, then displaying it may still be appropriate, but there's no point in taking other actions based on it.

(I've also had "Ongoing call" notifications stick around indefinitely — as in, I spotted it in the notification list literally days after the actual call. You'd think the notification would be removed when the call ends, but apparently that's not reliable. So, there may be some ways that can be improved.)