Linux: wrong app name in notification #715

Porkepix · 2020-04-12T08:37:17Z

Bug report

I understand the difference between Streamlink and Streamlink Twitch GUI.
This is a bug report and I have read the contribution guidelines.

Environment details

Operating system and version:
ArchLinux

Streamlink Twitch GUI version:
1.9.1

Streamlink version:
streamlink 1.3.1

Configuration details:
Gnome 3.36

Description

Since update a few weeks ago, streamlink-twitch-gui's notifications are not shown as being issued by "Streamlink Twitch GUI", but by "nwjs" instead. The same way, it doesn't use the project icon anymore, but use this one instead:

Expected / Actual behavior

It should use the correct issuer and icon for notifications.

Reproduction steps

Set up a Gnome computer
Log your account
Wait for a notification

As I believe issue happened after Gnome update or another component that was not streamlink-twitch-gui, I guess issue is rather that icon and issuer, maybe from electron, have changed of way to be used between now and previously. Can't say for sure what triggered the issue though.

The text was updated successfully, but these errors were encountered:

bastimeyer · 2020-04-12T09:25:57Z

Streamlink Twitch GUI is a NW.js application, not Electron. Anything regarding Electron is not relevant. This has also nothing to do with Gnome or any other desktop environment.

notifications are not shown as being issued by "Streamlink Twitch GUI", but by "nwjs" instead

Notifications are created via the chrome notifications API and on Linux, "freedesktop notifications" are being used as notification provider.

Streamlink Twitch GUI sets all parameters correctly which are available on the chrome notifications API. The "nwjs" part is set somewhere internally in NW.js's Chromium part, not sure where.

If this bug hasn't been fixed yet in the latest NW.js release, which Streamlink Twitch GUI is currently not using, so I can't tell, then this has to be reported on the NW.js bug tracker.

it doesn't use the project icon anymore

Icons on notifications are part of the freedesktop notification protocol. Streamlink Twitch GUI always sets an icon, either its own icon from the embedded files (png) when clicking the test notifications button in the settings menu or when it's a group-notification, or the Twitch channel's icon on single notifications (png or jpeg).

Other icons related to the app, eg. those loaded by task bars, app switchers, etc., are either icons of the freedesktop icon specification (the AUR package and the add-menuitem.sh in the regular release archive create these icons) or icons from the window's embedded icon on X11 (see #665).

Porkepix · 2020-04-12T09:56:07Z

Streamlink Twitch GUI is a NW.js application, not Electron. Anything regarding Electron is not relevant. This has also nothing to do with Gnome or any other desktop environment.

Sorry for the confusion. Not using these technologies and being not knowledgeable enough about those, I tended to consider every desktop application built upon Web technologies as being Electron applications, my bad.
While the issue reported here might not be related to Gnome, however I believe it started after a Gnome update. But indeed, it can be completely something else. What was anyway strange here is that streamlink-twitch-gui hasn't been updated for quite some time now, and that the issue clearly started long after the latest update.

it doesn't use the project icon anymore

Icons on notifications are part of the freedesktop notification protocol. Streamlink Twitch GUI always sets an icon, either its own icon from the embedded files (png) when clicking the test notifications button in the settings menu or when it's a group-notification, or the Twitch channel's icon on single notifications (png or jpeg).
* https://github.com/streamlink/streamlink-twitch-gui/blob/v1.9.1/src/app/services/notification/providers/chrome-notifications.js#L64

* https://github.com/streamlink/streamlink-twitch-gui/blob/v1.9.1/src/app/services/notification/dispatch.js#L54-L92

* https://github.com/streamlink/streamlink-twitch-gui/blob/v1.9.1/src/app/ui/routes/settings/notifications/controller.js#L46
Other icons related to the app, eg. those loaded by task bars, app switchers, etc., are either icons of the freedesktop icon specification (the AUR package and the add-menuitem.sh in the regular release archive create these icons) or icons from the window's embedded icon on X11 (see #665).

Just to clarify this: the issue I report relate only to Linux, probably Gnome desktop (I didn't launched others desktops recently. I might do those too), and only to notifications, both on the lock screen and in Gnome-shell.

Application icon in the alt-tab switcher is fine, as well as the one in gnome-shell and in Gnome menubar.
On Windows and mac computers, it indeed correctly use channel's icon and name the notification provider correctly.
I believe that before this bug, in Gnome, the notification issuer was correctly named, and notification used application's icon rather than channel's one, but which anyway is correct and much better than nwjs' one as the one shown in my first post.

bastimeyer · 2020-04-12T10:05:29Z

This is how the notify call works:
https://developer.gnome.org/notification-spec/

org.freedesktop.Notifications.Notify
  STRING app_name;
  UINT32 replaces_id;
  STRING app_icon;
  STRING summary;
  STRING body;
  ARRAY actions;
  DICT hints;
  INT32 expire_timeout;

If you trigger a custom notification from your shell, like this

gdbus call \
  --session \
  --dest org.freedesktop.Notifications \
  --object-path /org/freedesktop/Notifications \
  --method org.freedesktop.Notifications.Notify \
  my_app_name \
  1234 \
  gtk-dialog-info \
  "The summary" \
  "The body" \
  '["foo","bar"]' \
  '{}' \
  0

you'll see that the "my_app_name" string gets displayed the same way "nwjs" does when NW.js triggers a notification.

This means that NW.js is setting the wrong app name:

42.x (currently used version)
https://github.com/nwjs/chromium.src/blame/nw42-log/chrome/browser/notifications/notification_platform_bridge_linux.cc#L555
46.x (latest version)
https://github.com/nwjs/chromium.src/blame/nw46-log/chrome/browser/notifications/notification_platform_bridge_linux.cc#L574

The icon can either be a string identified by the freedesktop icon spec, which will be looked up from your /usr/share/icons or ~/.local/share/icons directories, or a custom icon, if it's set as a full path with a leading file:// scheme.

As I've already said, Streamlink Twitch GUI always sets a custom notification icon path. So if Gnome doesn't display custom icons, then it's ignoring the spec, simple as that.

Porkepix · 2020-04-12T10:21:37Z

Mmmh, then ok I understand all of the notification system is up to NW.js and freedesktop. What's strange though is that the code you're pointing to is identical for both releases, and looking at the blame untouched since three years.
Which makes me wonder what triggered the issue :/

bastimeyer · 2020-04-13T10:48:04Z

The bug just got fixed in NW.js:
nwjs/nw.js#7437 (comment)

The issue here will be resolved with a version bump and package.json upgrade. Bumping NW.js could potentially cause issues though, as some NW.js internals have changed between the currently used version and the latest (next) one. Will need to check this stuff first.

Porkepix · 2020-06-03T06:42:23Z

@bastimeyer Can we reopen this issue? Application name seems indeed fixed, but the icon is till the one I posted in my first post.

bastimeyer · 2020-06-03T08:35:41Z

the icon is still the one I posted in my first post.

As I've already pointed out, the correct icon URL according to Chromium's notifications interface is always set in the app code when sending a notification.

What Chromium does is reading the icon from the provided URL (a local file that was downloaded by Streamlink Twitch GUI before triggering the notification) and from what it looks like, it's transcoding it to a PNG and then writing it to the system's temp dir (/tmp). The icon path gets then added to the notification message as image-path and image_path "hint". As long as the notification is shown by your DE / notification server, this file will be kept in the temp dir. Afterwards, it gets deleted.

A regular "product icon" (the NW.js icon - or Chromium icon on upstream Chromium) is set as the regular icon field on the notification:

You can monitor the org.freedesktop.Notifications DBus interface and compare the messages with the interface description I've posted above:

$ dbus-monitor --session --monitor "interface='org.freedesktop.Notifications'"
method call time=1591172050.965156 sender=:1.6482 -> destination=org.freedesktop.Notifications serial=4 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=GetCapabilities
method call time=1591172050.965381 sender=:1.6482 -> destination=org.freedesktop.Notifications serial=5 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=GetServerInformation
method call time=1591172065.045018 sender=:1.6482 -> destination=org.freedesktop.Notifications serial=10 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=Notify
   string "Streamlink Twitch GUI"
   uint32 0
   string "file:///tmp/.io.nwjs.8mTqQ7"
   string "iceiceice has started streaming"
   string "Pango timbersaw day"
   array [
      string "default"
      string "Activate"
   ]
   array [
      dict entry(
         string "urgency"
         variant             uint32 1
      )
      dict entry(
         string "desktop-entry"
         variant             string "nw"
      )
      dict entry(
         string "image_path"
         variant             string "/tmp/.io.nwjs.qjXuV7"
      )
      dict entry(
         string "image-path"
         variant             string "/tmp/.io.nwjs.qjXuV7"
      )
   ]
   int32 25000
signal time=1591172076.807944 sender=:1.18 -> destination=(null destination) serial=29383 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=NotificationClosed
   uint32 112
   uint32 2

This means that the notification server / renderer needs to read the "real" icon from the image-path or image_path hints array. If it does not, then the product icon gets shown.

This is how Chromium implements this and it's neither a Streamlink Twitch GUI nor a NW.js issue.

However, I personally can't reproduce any notification icon issues while using the latest KDE Plasma version on Arch.

Porkepix · 2020-06-03T08:54:58Z

I'm also on latest versions on ArchLinux, but saw issues on Gnome. Gotta check it on KDE someday then, but it's strange that while it works well on many environments (your KDE, Windows, mac), it fails to do so there.

bastimeyer · 2020-06-03T09:21:10Z

If Gnome doesn't support the image-path or image_path hints set by Chromium, then it's an issue regarding Gnome's notification server / renderer. Chromium is following the notifications spec correctly.

The documentation of the org.freedesktop.Notifications interface says the following:

Icons and Images
A notification can optionally have an associated icon and/or image.

The icon is defined by the "app_icon" parameter. The image can be defined by the "image-path", the "image-data" hint or the deprecated "icon_data" hint.

Priorities
An implementation which only displays one image or icon must choose which one to display using the following order:

"image-data"

"image-path"

app_icon parameter

for compatibility reason, "icon_data"

Windows and macOS work completely different and have nothing to do with DBus and the notificiations interface.

Porkepix · 2020-06-03T10:34:59Z

I'm pretty much sure it used to work in the past. So my best guess considering that when it stopped to work there was no streamlink-twitch-gui update, is that there was a regression in Gnome.

That's however quite difficult to report bugs there considering privacy issues around GitLab's account creation.

bastimeyer · 2020-06-03T11:13:16Z

Once again, this is a bug in Gnome's desktop notification implementation. I think I found the problem though. If you want to report this bug, you can link to this post here, but this is it for me. I won't spend any more time on investigating bugs which are out of scope of my application by three or more layers.

As a reminder, this is the notification structure:
https://developer.gnome.org/notification-spec/

org.freedesktop.Notifications.Notify
  STRING app_name;
  UINT32 replaces_id;
  STRING app_icon;
  STRING summary;
  STRING body;
  ARRAY actions;
  DICT hints;
  INT32 expire_timeout;

As another reminder, this is how the specification describes icon/image priority:

An implementation which only displays one image or icon must choose which one to display using the following order:

"image-data"

"image-path"

app_icon parameter

for compatibility reason, "icon_data"

As I've already pointed out earlier, Chromium sets the "icon" which is set by the app code via the chrome.notifications API as an image-path field to the notification's hints array and it sets its own "product icon" on the regular app_icon property. The app_icon was empty prior to this commit in Chromium, which is probably the reason why earlier Chromium versions were working fine according to your comment:
chromium/chromium@141f543#diff-c1dac52d37c9a066f42dd729ac44500bR526-R532

This is how Gnome handles the icon/image situation when reading a notification:
https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/master/js/ui/notificationDaemon.js#L253

let gicon = this._iconForNotificationData(icon);
let gimage = this._imageForNotificationData(hints);
if (!gicon && gimage)
    gicon = gimage;

As you can see, according to the documentation, this is not how it's supposed to be handled. The image-path of the hints array should always take precedence if it is available. Gnome violates this rule by only using the image if no icon is set. Since Chromium always sets an icon no matter what, the image (which is the real "twitch-channel-icon" set by Streamlink Twitch GUI) gets ignored.

Porkepix · 2020-06-03T11:57:34Z

Sorry, didn't wanted to be annoying or anything else, as said in my previous comment, I understand well this is a regression in other layers.

Porkepix · 2021-03-19T22:48:49Z

Just as an information for anyone that would read here and for the record, seems like it was fixed in https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1616, from issue https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3616
Fix is backported in Gnome 3.36 and 3.38.

On the other hand, I thought the option was there, I'm thinking one might prefer simple Twitch GUI standard icon for everything to pick?

bastimeyer changed the title ~~Wrong icon and notification author with recent version of Gnome/electron~~ Linux: wrong app name in notification Apr 12, 2020

bastimeyer added os: Linux platform issue labels Apr 12, 2020

bastimeyer mentioned this issue Apr 12, 2020

Linux: wrong app name in native desktop notifications nwjs/nw.js#7437

Closed

bastimeyer closed this as completed in 9c53ed3 May 9, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Linux: wrong app name in notification #715

Linux: wrong app name in notification #715

Porkepix commented Apr 12, 2020 •

edited

Loading

bastimeyer commented Apr 12, 2020

Porkepix commented Apr 12, 2020 •

edited

Loading

bastimeyer commented Apr 12, 2020

Porkepix commented Apr 12, 2020

bastimeyer commented Apr 13, 2020

Porkepix commented Jun 3, 2020

bastimeyer commented Jun 3, 2020

Porkepix commented Jun 3, 2020

bastimeyer commented Jun 3, 2020

Porkepix commented Jun 3, 2020

bastimeyer commented Jun 3, 2020 •

edited

Loading

Porkepix commented Jun 3, 2020

Porkepix commented Mar 19, 2021

Linux: wrong app name in notification #715

Linux: wrong app name in notification #715

Comments

Porkepix commented Apr 12, 2020 • edited Loading

Bug report

Environment details

Description

Expected / Actual behavior

Reproduction steps

bastimeyer commented Apr 12, 2020

Porkepix commented Apr 12, 2020 • edited Loading

bastimeyer commented Apr 12, 2020

Porkepix commented Apr 12, 2020

bastimeyer commented Apr 13, 2020

Porkepix commented Jun 3, 2020

bastimeyer commented Jun 3, 2020

Porkepix commented Jun 3, 2020

bastimeyer commented Jun 3, 2020

Porkepix commented Jun 3, 2020

bastimeyer commented Jun 3, 2020 • edited Loading

Porkepix commented Jun 3, 2020

Porkepix commented Mar 19, 2021

Porkepix commented Apr 12, 2020 •

edited

Loading

Porkepix commented Apr 12, 2020 •

edited

Loading

bastimeyer commented Jun 3, 2020 •

edited

Loading