[Snap] Notifications don't follow freedestkop standards when using 'core20' base
Categories
(Firefox Build System :: Third Party Packaging, defect, P4)
Tracking
(Not tracked)
People
(Reporter: samlane00, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0
Steps to reproduce:
Using the Snap version of Firefox on Ubuntu Budgie 22.10 / 23.04, produced a notification from a website. Notification did not show from snap version despite working from the ESR version. I used dbus-monitor to examine the org.freedesktop.Notifications interface for the "desktop-entry" hint sent by Firefox
Actual results:
Firefox Snap version sends the "desktop-entry" hint as "/snap/firefox/<revision>", in this case it was "/snap/firefox/2391".
(non-snap ESR version simply sends "Firefox")
Expected results:
According to freedesktop notification standards:
"desktop-entry": This specifies the name of the desktop filename representing the calling program. This should be the same as the prefix used for the application's .desktop file. An example would be "rhythmbox" from "rhythmbox.desktop". This can be used by the daemon to retrieve the correct icon for the application, for logging purposes, etc.
I would expect that the snap version of Firefox would also send the correct name of the .desktop file, instead of a path to where it appears to be, as this makes it impossible for some environments that require this .desktop file to properly handle notifications. In my instance, this causes notifications to fail to show because the daemon is expecting a desktop file name, not a path.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•2 years ago
|
|
||
Comment 2•2 years ago
|
||
Could you please provide clear STR ? Notifications are working for me.
|
|
||
Updated•2 years ago
|
Using the Snap version of Firefox on Ubuntu Budgie 22.10 / 23.04, latest Budgie Desktop 10.7.1
From the terminal, I ran "dbus-monitor interface=org.freedesktop.Notifications"
For this example, i used https://web-push-book.gauntface.com/demos/notification-examples/
I enabled notifications through the website, and clicked the "Title & Body" demo notification.
Here is the output:
string "Firefox"
uint32 0
string ""
string "Simple Title"
string "Simple piece of body text.
Second line of body text 👍"
array [
string "default"
string "Activate"
]
array [
dict entry(
string "desktop-entry"
variant string "/snap/firefox/2391"
)
dict entry(
string "suppress-sound"
variant boolean false
)
]
int32 -1
If you notice, the string "desktop-entry" sent is /snap/firefox/2391
According to freedesktop standards, this "desktop-entry" string should be the prefix of the .desktop file for Firefox. Instead, this is a path.
https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html#hints
Similar test using the .deb version
string "Firefox"
uint32 0
string ""
string "Simple Title"
string "Simple piece of body text.
Second line of body text 👍"
array [
string "default"
string "Activate"
]
array [
dict entry(
string "desktop-entry"
variant string "Firefox"
)
dict entry(
string "sender-pid"
variant int64 5274
)
]
int32 -1
In this instance, the hint string "desktop-entry" sent is Firefox, which can be correctly used by the notifications daemon for the Budgie desktop.
The reason it matters in this case is the Budgie Desktop uses this hint to determine whether the notification should be shown. Since the snap sends a path instead of the .desktop file name for the "desktop-entry", this lookup fails and Budgie Desktop does not show the notification. Again, this does not affect the .deb version (which works fine) or other snaps. Also, admittedly, this issue may only affect the Budgie Desktop and not other desktop environments, and while it is possible to raise an issue with the Budgie Desktop developers, this would only be a workaround. For me, personally, it seems odd the snap version sends the desktop-entry hint as a path when most notification systems are expecting otherwise.
For clarification, I believe it is important to note that my issue is NOT about notifications not showing. It is strictly limited to the "desktop-entry" hint not following the Freedesktop notification standard, which makes it more difficult for OS notification daemons that rely on this hint to function as intended (to determine whether notifications are enabled/disabled, to pull the correct icon from the .desktop file, etc).
|
|
||
Comment 5•2 years ago
|
||
Ok, so it only impacts non GNOME desktop ? Can you verify with current nightly binaries as well ? I'm unsure where in the code this is being sent from
While the GNOME desktop of Ubuntu 22.10 isn't affected by the side-effect of the notification not showing, testing on a fresh install of 22.10, the "desktop-entry" hint is still incorrect on GNOME. Tested the nightly, same issue. Again, its only the snap version. The .deb uses "firefox" as the hint, the flatpak uses "org.mozilla.firefox" as the hint, which makes sense as the flatpak desktop file is "org.mozilla.firefox.desktop".
Now the interesting part is on a recently updated 23.04 beta version of Ubuntu, this issue does not happen with the most recent stable snap (revision 2487). It correctly sends the desktop hint as "firefox_Firefox", which makes sense as the desktop file for the snap is "firefox_firefox.desktop".
I notice in toolkit/system/gnome/nsAlertsIconListener.cpp:
// If MOZ_DESKTOP_FILE_NAME variable is set, use it as the application id,
// otherwise use gAppData->name
if (getenv("MOZ_DESKTOP_FILE_NAME")) {
// Send the desktop name to identify the application
// The desktop-entry is the part before the .desktop
notify_notification_set_hint(
mNotification, "desktop-entry",
g_variant_new("s", getenv("MOZ_DESKTOP_FILE_NAME")));
} else {
notify_notification_set_hint(mNotification, "desktop-entry",
g_variant_new("s", gAppData->remotingName));
}
So if I am reading things correct (SPOILER ALERT I may not be) it looks like it is trying to do things properly, but something goes wrong with the snap version on 22.10 and earlier.
However, since I am no longer seeing this issue on the Ubuntu 23.04 beta, if the newer versions of the firefox snap continue to pass the correct hint (while passing the incorrect one on older versions of Ubuntu) the logical conclusion I guess is that this is a snap issue and not a Firefox issue.
|
|
||
Comment 7•2 years ago
|
||
If you're right on 22.10 vs 23.04, then it would be an issue lying around something else than us.
|
|
||
Comment 8•2 years ago
|
||
When you tested 22.10 vs 23.04, was the Firefox version the same? Snap revision would be different, but was it the same Firefox ? Wondering because the .desktop file is directly pulled from out code on all branches I could check: https://github.com/canonical/firefox-snap/blob/7a61764714c5e486b9c43644900e654b0e3fb7ae/snapcraft.yaml#L310
On 23.04 I have snap rev 2453, which says version 111.0-2 (working one). On 22.10 I have rev 2487, which is 111.0.1-2 (non-working one). Interesting now though, I tried the nightly this morning on one of my other 23.04 installs and it wasn't working correctly so I purged and reinstalled. Now on that machine I have 111.0.1-2 (snap rev 2487) and it again is not working. So now I am not sure, is there any logical reason why the two versions (111.0-2 vs 111.0.1-2) would differ, or is it indeed an underlying snap issue and not a Firefox issue at all...
|
|
||
Comment 10•2 years ago
|
||
At least when created, RemotingName we send should be read from https://searchfox.org/mozilla-central/rev/0907529ff72c456ddb47839f5f7ba16291f28dce/toolkit/xre/CreateAppData.cpp#60. Here:
$ grep RemotingName /snap/firefox/current/usr/lib/firefox/application.ini
RemotingName=firefox
And this is on 22.04, with snap rev 2487
|
|
||
Comment 11•2 years ago
|
||
Can you try forcing MOZ_DESKTOP_FILE_NAME=xxx snap run firefox ? This should make sure we control what happens
|
|
||
Comment 12•2 years ago
|
||
Here I repro and MOZ_DESKTOP_FILE_NAME has no impact.
|
|
||
Comment 14•2 years ago
|
||
Ok so the behavior differs because of core22. Try snap refresh --amend firefox --channel=candidate/core22 and you can see, firefox_Firefox being sent. This is definitively an issue at the packaging level.
(please note core22 is not yet ready, so maybe you dont want to mess your setup too much)
|
Reporter | |
Comment 15•2 years ago
|
||
I'll hold off on my daily driver, but tested this on a couple installs including my 22.10. Yes, i can confirm it is working correctly. I do appreciate the time you have spent on this.
|
||
Updated•2 years ago
|
|
|
||
Comment 16•2 years ago
|
||
The severity field is not set for this bug.
:gerard-majax, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 17•2 years ago
|
||
Just an update, this issue appears to be resolved (at least for me anyways). Currently on Ubuntu 22.04/22.10 using 115.0-2 (core20) .
Output from dbus-monitor:
array [
dict entry(
string "desktop-entry"
variant string "firefox_Firefox"
)
Snap info:
base: core20
snap-id: 3wdHCAVyZEmYsCMFDE9qt92UV8rC8Wdk
tracking: latest/stable/ubuntu-22.04
refresh-date: yesterday at 13:42 EDT
channels:
latest/stable: 115.0-2 2023-07-04 (2850) 256MB -
latest/candidate: 115.0-2 2023-07-01 (2850) 256MB -
latest/beta: 116.0b1-1 2023-07-04 (2865) 252MB -
latest/edge: 117.0a1 2023-07-06 (2877) 262MB -
esr/stable: 115.0esr-2 2023-07-06 (2858) 256MB -
esr/candidate: 115.0esr-2 2023-07-02 (2858) 256MB -
esr/beta: ↑
esr/edge: ↑
installed: 115.0-2 (2850) 256MB -
Not sure when the issue stopped happening, but testing on an older install of 114.0.2-1 (2800), it was also working correctly.
Again thanks for your time.
|
|
||
Comment 18•2 years ago
|
||
Thanks, it's weird but there's not much we can do then.
Description
•