Open Bug 1807809 Opened 3 years ago Updated 1 year ago

[Wayland] libnotify: Dbus timeouts when sending/closing Notifications, build-in notifications are misplaced

Categories

(Core :: Widget: Gtk, defect, P3)

Firefox 110
defect

Tracking

()

UNCONFIRMED

People

(Reporter: me, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

For a while now I've been experiencing an intermittent problem where sometimes Firefox will fail to send a native notification. What causes this is unknown but after some investigation I hypothesise that this is due to sending too many requests to the notification server, too quickly.

When this happens it causes Firefox to fallback to its built-in notifications which are especially annoying on Wayland since Kwin (I am running Plasma Wayland) places the window randomly on the screen. This is very annoying and the main reason I finally decided to try to debug this.

I added some debugging code to nsAlertsIconListener.cpp to better log what is going on to try to understand the problem.

Some of the errors I noticed with this added logging code are as follows:

[Parent 13381: Main Thread]: D/libnotify Close::error:code: 24
[Parent 13381: Main Thread]: D/libnotify Close::error:domain: 278
[Parent 13381: Main Thread]: D/libnotify Close::error:message: Timeout was reached

This error message comes from Glib and is because Dbus is timing out for some reason:

/usr/src/debug/dev-libs/glib-2.74.4/glib-2.74.4/gio/gdbusconnection.c

1882   │ /* Called from a user thread, lock is not held; @task is (transfer full) */
1883   │ static gboolean
1884   │ send_message_with_reply_timeout_cb (gpointer user_data)
1885   │ {
1886   │   GTask *task = user_data;
1887   │ 
1888   │   send_message_data_deliver_error (task, G_IO_ERROR, G_IO_ERROR_TIMED_OUT,
1889   │                                    _("Timeout was reached"));
1890   │   return FALSE;
1891   │ }
[Parent 13381: Main Thread]: D/libnotify ShowAlert::error:code: 36
[Parent 13381: Main Thread]: D/libnotify ShowAlert::error:domain: 278
[Parent 13381: Main Thread]: D/libnotify ShowAlert::error:message: GDBus.Error:org.freedesktop.Notifications.Error.ExcessNotificationGeneration: Created too many similar notifications in quick succession

This error message is very infrequent (I've only seen it once) and comes from this code in Plasma's notification server which is throttling the speed at which an application can send duplicate notifications.
Why Firefox can send duplicate notifications I'm not sure. This is probably a buggy website's fault rather than Firefox's fault.

/usr/src/debug/kde-plasma/plasma-workspace-9999/plasma-workspace-9999/libnotificationmanager/server_p.cpp

 213   │     // If multiple identical notifications are sent in quick succession, refuse the request
 214   │     if (m_lastNotification.applicationName() == notification.applicationName() && m_lastNotification.summary() == notification.summary()
 215   │         && m_lastNotification.body() == notification.body() && m_lastNotification.desktopEntry() == notification.desktopEntry()
 216   │         && m_lastNotification.eventId() == notification.eventId() && m_lastNotification.actionNames() == notification.actionNames()
 217   │         && m_lastNotification.urls() == notification.urls() && m_lastNotification.created().msecsTo(notification.created()) < 1000) {
 218   │         qCDebug(NOTIFICATIONMANAGER) << "Discarding excess notification creation request";
 219   │ 
 220   │         sendErrorReply(QStringLiteral("org.freedesktop.Notifications.Error.ExcessNotificationGeneration"),
 221   │                        QStringLiteral("Created too many similar notifications in quick succession"));
 222   │         return 0;
 223   │     }

There are two issues I see with Firefox here:

  • Firefox should ideally handle this situation better than returning NS_ERROR_FAILURE and never using native notifications ever again for the duration that it's open (if for any reason Dbus times out even once it'll never, ever try to use native notifications again!).

  • The fallback notification window should ideally behave better on Wayland. It's very annoying that they are placed randomly on the screen. If you have another application open and focused, the notification window will steal focus away from where you were; you could say this is a bug in Kwin but it's Firefox that's causing it.

Since patching Firefox with a workaround to ignore timeouts I've not had to deal with the annoying fallback notifications since.

With the logging above, did you find why firefox switches back to build-in notifications?

Also maybe we can do a special adjustment for Wayland to disable build-in notification or create them as popups and make them connected to toplevel window.

Blocks: wayland
Priority: -- → P3
Summary: libnotify: Dbus timeouts when sending/closing Notifications → [Wayland] libnotify: Dbus timeouts when sending/closing Notifications, build-in notifications are misplaced
Flags: needinfo?(me)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #1)

With the logging above, did you find why firefox switches back to build-in notifications?

It happens if the Dbus connection fails/disconnects for some reason. I couldn't figure out why that happened. I don't know if it was a problem with Firefox or an issue with libnotify or even if it was an issue with KDE Plasma's notification daemon.

The weird thing about this was that only Firefox was affected but that could have just been a coincidence.

There's been a lot of updates on my system since and I can't reproduce this anymore. It used to happen without fail if I left Firefox running long enough.

Also maybe we can do a special adjustment for Wayland to disable build-in notification or create them as popups and make them connected to toplevel window.

Would that fix the focus-stealing?

I don't know if that's a KWin issue or expected behaviour but that was the thing I found most annoying about the built-in notifications.
When the window launches it automatically takes focus from whatever else you were doing. I don't know if there's some sort of hint that could tell KWin not to do that?

Flags: needinfo?(me)

(In reply to Aidan Harris from comment #2)

Would that fix the focus-stealing?

I don't know if that's a KWin issue or expected behaviour but that was the thing I found most annoying about the built-in notifications.
When the window launches it automatically takes focus from whatever else you were doing. I don't know if there's some sort of hint that could tell KWin not to do that?

I have no idea.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: