Notifications being a PITA

[uniquePWD]

Notifications are lingering, not disappearing until they've been hovered over.

Also can we get a setting to make them permanent or temporary in the notification centre?

[andyholmes]

I'm not exactly sure which notifications you're referring to. Are these SMS notifications, notifications that have been withdrawn by the remote device or all?

Generally notification interactions are managed by gnome-shell, so any UX modifications should probably be done by a 3rd party extension.

[uniquePWD]

It's literally all of the noticiations that KDEConnect is sending via GSConnect. They were working fine in v12 (pre-Gnome 3.30) however since the update (which admittedly could be a change in Gnome), the notifications linger. Whether Telegram, TypeApp, Tutanota, Signal. They're not vanishing straight away.

I'm on Ubuntu 18.10 if that helps.

[andyholmes]

I believe there is a timeout for notifications. If there are buttons, the banner needs to expand or the notifications are repliable, your only chance to do use those features is when the notification first pops up.

Once they're in the message tray, you can't do any of those.

[uniquePWD]

That's the thing, they're not timing out, they're just sitting at the top of the screen. The ones that are repliable are even stealing keyboard focus on occasion.

[andyholmes]

Hmm, for me repliable notifications timeout after 5 seconds. Hovering them expands the banner and focuses the entry, just like telepathy notifications. At that point they won't timeout, because any timeout would apply your chance to actually type in the entry field.

[uniquePWD]

They're definitely lasting longer than five seconds. Another symptom is that when I unlock my laptop, I will get all the notifications going back to whenever my screen timed out.

[andyholmes]

They definitely shouldn't be lasting any longer than normal, the only change to the notification is the added text entry, otherwise they're direct subclasses of regular notifications.

As far as notifications when your screen is off, they're sent by the service just like regular notifications. If they weren't you would just never get them, and I don't think there's a reasonable way to tell if the screen is blanked/locked or what could be done if it were.

EDIT I'm just going to mark this as "needs discussion", because it's unclear whether this is a UX issue with Gnome Shell, their notifications, our repliable notifications, or if GSConnect is somehow causing either of those to misbehave.

[andyholmes]

Upstream report in gnome-shell, possibly related to this discussion: https://gitlab.gnome.org/GNOME/gnome-shell/issues/112

[andyholmes]

Since we don't change notification behaviour or timeouts this is an upstream UX issue, so I'll close it.

[ferdnyc]

I know this is closed, but I wanted to mention that I've seen hints of the same thing, but only for certain specific notifications. With my phone, it's been very few notifications, but I think that's because I have KDE Connect's list of apps to mirror notifications from severely limited, and primarily to ones which don't trigger it. (GMail, Messages — over 95% of my notifications are from one of those two apps, which do time out happily or scram on a quick hover.)

The ones that don't play so nicely, and seem to linger indefinitely even if I buzz them with the mouse pointer, forcing me to actually use the notification's close icon to dismiss them, are (for me) primarily YouTube notifications. Though I may have seen it with others on occasion.

What seems to set the stubborn notifications apart is that they contain a hyperlink embedded in the notification. Based on some assumptions/impressions, and far-from-rigorous observations, it feels to me like that may be the determining factor. If I see any blue text in the notification popup, I'm going to have to drag my mouse up there and actually click the close icon to make it go away.

It's possible GNOME Shell has different timeout/dismissal rules, accidentally or intentionally, for notifications containing web links.

[andyholmes]

I think you can usually make notifications retreat to the message tray just by re-asserting the focus elsewhere (eg. click somewhere that isn't the notification).

From fmeullner's description in the above bug report, it seems like "explicit inactivity" will result in the notifications hanging around. I believe the example he used is walking away from your desktop for a coffee while the screen is still on, so it must be inferred from the lack of typing and mouse movement that you haven't seen it. Which is a pretty good rationale to me, although I could see how it could be a matter of opinion.

It's possible GNOME Shell has different timeout/dismissal rules, accidentally or intentionally, for notifications containing web links.

I know one trigger for notifications to hide is losing focus, which is usually obvious since few notifications have focusable elements. For example in our repliable notifications, which were more or less copied from the telepathy notifications:

https://github.com/andyholmes/gnome-shell-extension-gsconnect/blob/c3ff28293fcdbb7f938579f4b55e9b642d1e8c55/src/shell/notification.js#L37-L43

You see how we have to explicitly emit a signal telling the Shell we've "forfeited" the input focus. This is a signal specific to the notification system, which indicates some part of Gnome Shell is paying attention.

Oddly, the one Pango element Clutter doesn't have support for is hyperlinks, so those are manually implemented. It's possible the related signal has been overlooked, in which case it might be worth reporting.

[ferdnyc]

I know one trigger for notifications to hide is losing focus, which is usually obvious since few notifications have focusable elements.

Well... is that talking keyboard focus, or window focus? Nearly any visible window can receive window focus, AIUI. (Excepting a few explicitly-unfocusable utility types, like a Conky window for example.) And I believe that's true regardless whether any of its internal elements accept keyboard focus — for one thing, that's how the terrible, stupid, bad-idea Application Menu would determine which application it should show as the "active" one: by tracking where window focus went.

In the Window pane of gnome-tweaks, I have my desktop configured "Window Focus: Focus on Hover", with "Raise Windows When Focused" turned off. And sure enough, the way I dismiss most notifications is by buzzing them with my mouse pointer — just a quick mouse-over-the-notification, mouse-back-out-again. I don't have to click anything, as long as I'm there long enough for the window focus to be transferred into the notification popup, and then back out again.

It hasn't been my experience that even clicking outside of them will dismiss them, and since I don't use "Click To Focus" I wouldn't really expect it to. (They probably do time out and go away on their own after some number of seconds, if I'm actively using the computer, but since a popped-up one is usually covering part of my browser window I tend to swing the mouse its way to get rid of it immediately.)

[andyholmes]

Well... is that talking keyboard focus, or window focus?

Technically, it's probably window focus, although in this case GNOME Shell has it's own concept of focus specific to notifications since dealing with "magical floating widgets" that arbitrarily appear, disappear and relocate themselves to the message tray is a bit tricky.

On the other hand, gaining input focus usually results in the containing window receiving focus (remembering we're probably talking about the the Clutter version of GdkWindow, not GtkWindow).

[uniquePWD]

Would it be possible for GSConnect to set the notification priorities to the minimum, could that possibly somewhat mitigate the problem?

[andyholmes]

Notifications in gnome-shell are really an abstraction of libnotify and GNotifications and have (essentially) three levels:

• Low: immediately hide in the tray and don't popup
• Normal: show with (usually ~4s) a timeout (most notifications)
• High: show and never hide without direct interaction (we use these for fraudulent certificate attempts)

There's actually a fourth between high & normal that we rarely use, but there's no way for us to change the notification timeout or behaviour without affecting notifications globally. Changing this is probably be better done by a third-party extension, since that's out of scope for GSConnect to start affecting everyone else's notifications. We're lucky the reviewers let the changes we do make pass since they persist even if GSConnect is uninstalled:

https://github.com/andyholmes/gnome-shell-extension-gsconnect/blob/ced339fc78a6b0dca4ecfe90d09218e2122693a4/src/extension.js#L492-L497

For reference there is an upstream issue about redesigning notifications here and a slew of open issues about notifications that might be relevant to get involved in.

[ferdnyc]

Heh! So, turns out the lingering notifications that I'd been seeing, the ones with hyperlinks in them, aren't from GSConnect at all — they're web push notifications popped up by Chrome. I just got one now, saw that it had a "Settings" button at the bottom, and clicked it to find myself staring at the Chrome notification permissions page.

So, that explains that. Sorry for the misdirection. But, yeah, looks like I haven't actually been seeing any "sticky" notifications from GSConnect.