Notification issues

This may be useful, this may be useless, I am not too experienced in the linux world, but it looks to me like when Chromium sends a notification, it makes a temporary icon, and passes that to the notifications. From my untrained eye, it looks like there are two issues. One is that the case doesn’t match. For example, the temporary icon name in this instance (which always changes) is “org.chromium.Chromium.CVLIQx”. However, if I add a print statement to Raven to print the icon name, it seems it is trying to find this file with all lowercase letters maybe? Also, it looks like with the Chromium snap, the file it is looking for is “/tmp/.org.chromium.chromium.cvliqx”, but the file is actually created as “/tmp/snap.chromium/tmp/.org.chromium.Chromium.CVLIQx”. So not only does the case not match, the location doesn’t match either. I attached a screenshot of what I mean. The bottom red rectangle is the print command in Raven for the icon name.

Hopefully this is of some use…

2 Likes

Interesting behaviour. Which bit of code are you referring to? Link?

Line 583 is where I had the print(app_icon). Line 582 I just realized is where it it is made lowercase. However, commenting that out has no effect other than making it print the file name correctly. It is still broken.

1 Like

I’m not that good at coding. Maybe some day, but I am still in the very early stages of learning Vala, Gtk, etc… However, I did change the notifications_view.vala to make the notifications show icons for at least the current versions of Chromium, Chrome, and Vivaldi. It is really hacky and I don’t love it, because it pretty much hard codes specific conditions for these three apps, but it does work to fix the broken icons.

I’m hoping it at least is a good starting point for someone with a bit more experience than me to maybe fix it the right way.

Or if nothing else, its a patchwork fix for someone annoyed by the broken icons.

The changes I made are on lines 397-411, and on line 597.

ALSO:
I am pretty sure I am wrong about the lowercase being an issue. That seems to happen after the initial popup with the broken image is already displayed. The real issue seems to be that the temporary generated icon is in the snap, so the path is passed incorrectly, and also on top of that, Raven seems to not like the “file:///” format.

It seems only Chromium puts the icon in /tmp/snap.chromium/tmp. Chrome and Vivaldi put theirs directly into /tmp

EDIT: Removed link - upstream merged more appropriate fix posted further down in topic

1 Like

thanks for the hints. Looks like the thinking cap needs to be pushed harder - so we have deb vs snap issues and weird icon names to contend with.

hmm…

Aaah snap.

A common thing with any snap : they don’t follow legacy paths to store configs, don’t follow freedesktop recommendations.

So any other app’s or DE features ( ie. thumbnails, notifications… ) expecting to find something in ~/.app-name, ~/.config or ~/.local/share or ~/.cache might get broken with snap-app’s.

Those other app’s or features should also query what they need from ~/snap/… since snap will never send anything into ~/.anywhere ( hidden files and folders are out of reach for snap ).

A bit of a shame that Ubuntu ( sharing same mother-home as snap ) does not itself interact better with snap.

I have more notes on this. I’m at work for 5 more hours but I’ll post them after. Bottom line is it seems as if you tell Raven to ignore the icons with the “file:///“ prefix, Raven defaults to showing the image passed by the browser, instead of the icon. In the case of a .deb, it shows up as the same image passed by Firefox (i.e the website icon). This is probably the preferred behavior anyways.

In the case of a snap, it defaults to a generic notification icon. But even that seems preferable to a broken image. But the .debs of Chrome, Opera, and Brave all seem to work as intended.

I may be wrong about this, but this is what i THINK happens based on the Raven source…

When it has a notification, it first looks at the icon name sent. (This is what chromium based browsers are sending with the “file:///” prefix, that appears to be breaking the icons) If the icon is a file location, it loads the icon. It determines if it is an icon name or a file by seeing if a “/” is in the name.

If that doesn’t work, it tries to load the image sent by the website. This is probably the preferred behavior, because then you get the website’s icon instead of just the default browser icon.

If that doesn’t work, it looks like it tries to find an icon based on the .desktop file if it finds one for the app name sent by the notification.

If that doesn’t work, it defaults to a generic icon (mail-unread-symbolic).

Since chromium-based browsers are sending the name prefixed with “file:///”, it is causing it to fail. If I change it with just one thing:

if ("file:///" in app_icon){
        app_icon = "";
}

Raven will now handle the image the way I think it should. What happens with that fix is that the .deb versions of browsers now show the image passed by the website (Brave, Opera, Vivaldi, Chrome). The snap version of Opera can’t get the icon from the snap, however it now correctly defaults to the Opera logo. Chromium however, doesn’t seem to play nice, but nevertheless, it defaults now to the “mail-unread-symbolic” icon instead of the broken image.

I attached a picture of how it looks with the fix. #1 is the snap Opera, #2 is how Chrome, .deb Opera, Vivaldi, and Brave all look. #3 is Chromium.

1 Like

Well I’m fully admiring.

Did you report these upstream → https://github.com/solus-project/budgie-desktop/issues?q=raven ?

That’s a pretty obvious fix :smiley: could you make a PR upstream please? That way, instead of a patch, users on solus, manjaro, and other distros will benefit from it too

Done.

Hopefully correctly… first time doing a PR…

1 Like

That’s great! :smiley:
Hopefully it’s accepted

Hi all

I’m now looking at pushing a future update to 20.04 to resolve this.I need a bug report though to fix against.

Please can you run:

ubuntu-bug budgie-desktop

Let me know what the bug report number is. TIA

Do you just want a bug report about chrome based notifications in general not working correctly? Or something specific?

Yep … just that, the notifications not working via ubuntu-bug for 20.04

Reported under Bug #1895697

A budgie-desktop fix is now rolling out to resolve this. Just update as usual. Thx

Indeed.

Does what’s described at Notification issues meaning it’s still half broken with chromium as a snap.

There is a fix, kinda…

The problem is, it tries to find the icon for Chromium using the “chromium.desktop” file. The snap version however, calls this file “chromium_chromium.desktop” instead. So what I do, is I copy

/var/lib/snapd/desktop/applications/chromium_chromium.desktop

to

~/.local/share/applications

Then I rename the local copy of this file “chromium.desktop” instead.

You should see the chromium icon for notifications now, but the drawback is you will have Chromium listed twice in the menu, so I use menulibre to hide the new one.

This also doesn’t seem specific to Chromium. Opera snap has the same issue, and probably others.

Nice catch ! I did not notice duplicate entries in app menu, as for some app’s ( gimp and chromium ) I use them only as snap.

But you’re right, it seems snap’s .desktop have app_app.desktop for names.
This for avoiding they replace the « legacy » ones app.desktop. Safe logic finally.

Hope you won’t bother I quote you here
https://forum.snapcraft.io/t/notifications-in-chromium-show-generic-icon/21079
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1903893

1 Like