According to the spec at https://developer.gnome.org/notification-spec/, notification servers should support the following html tags or otherwise strip them: b, i, u, a, img.
Unfortunately, "a" and "img" tags are neither supported nor stripped, leaving the html markup in the notification body.
I'm not sure if this is the right place to post this issue since the notification-daemon is archived. Feel free to move it to any appropriate repo.
(edit: This comment isn't 100% accurate, see the comment below!)
The notification spec has a rowstride
argument for image-data
, which is separate from the existing information in width
/ bits_per_sample
/ channels
.
However, in _notify_daemon_pixbuf_from_data_hint
, notification-daemon does:
expected_len = (height - 1) * rowstride + width
* ((n_channels * bits_per_sample + 7) / 8);
if (expected_len != g_variant_get_size (data_variant)) {
g_warning ("Expected image data to be of length %" G_GSIZE_FORMAT
" but got a " "length of %" G_GSIZE_FORMAT,
expected_len,
g_variant_get_size (data_variant));
return NULL;
}
i.e. it requires the rowstride to be minimal instead of ignoring the padding (which I think gdk_pixbuf_new_from_data
does just fine!). I think it'd make sense for this check to use expeced_len < ...
instead?
Having such padding can be useful to optimize image operations on the stored image data, and would allow applications to send the existing image data with padding, without having to reorganize (and/or copy) it. In my case, I'm implementing notification support in qutebrowser, which gets the image data from the underlying QtWebEngine / Chromium, but Chromium seems to pad the data so that every scan line is on a 4-byte-boundary.
The spec also says:
This image format is derived from gdk-pixbuf.
and their documentation also hints at this being somewhat usual:
The
gdk_pixbuf_new()
function will compute an optimal rowstride so that rendering can be performed with an efficient algorithm.
So this could potentially affect other applications using GDK pixbufs as well.
Note that GNOME Shell seems to do the right thing from a quick look - it's only this repository (and many other notification daemons likely derived from it) suffering from this issue.
(As an aside: I'm opening issues similar to this in many different notification daemons, since I've found various of them suffering from this issue. I've taken care to avoid copy-paste mistakes and include specific details, but if I've missed something, I apologize. FWIW, so far I know that GNOME Shell, KDE Plasma, awesomewm and Cinnamon handle this correctly, but most others do not)
notification-daemon
is not under active development anymore and had its last code changes more than five years ago. Its codebase has been archived at https://gitlab.gnome.org/Archive/notification-daemon/
Closing this report as WONTFIX to reflect reality.
I am using libnotify and notification-daemon on Gentoo and when google-chrome passes <a href=http://foo.com>bar</a>
style links, they are not shown as hyperlinks in the message as one would expect (Example). I have checked to see that hyperlinks are supported and they are:
aquarius% dbus-send --dest=org.freedesktop.Notifications --print-reply --type=method_call /org/freedesktop/Notifications org.freedesktop.Notifications.GetCapabilities
method return time=1612386431.686488 sender=:1.9 -> destination=:1.1290 serial=1928 reply_serial=2
array [
string "actions"
string "body"
string "body-hyperlinks"
string "body-markup"
string "icon-static"
string "sound"
string "persistence"
string "action-icons"
]
aquarius%
notification-daemon
is not under active development anymore and had its last code changes more than five years ago. Its codebase has been archived at https://gitlab.gnome.org/Archive/notification-daemon/
Closing this report as WONTFIX to reflect reality.
The following Merge Request (MR) has been forwarded from GitHub in order to prevent the GNOME Project from losing contributions coming from un-official channels. And for contributors to not see their valuable contributions not being accounted for.
Relevant information:
Github handle: GH-TpaeFawzen
MR URL: https://github.com/GNOME/notification-daemon/pull/1
Patch URL: https://github.com/GNOME/notification-daemon/pull/1.patch
Body of the MR:
Just use case statements instead of calling test -z or test =; while test command is not always a built-in, case statement is so everywhere. Also you can prefix left-parenthesis to pattern with right-parenthesis.
notification-daemon
is not under active development anymore and had its last code changes more than five years ago. Its codebase has been archived at https://gitlab.gnome.org/Archive/notification-daemon/
Closing this report as WONTFIX to reflect reality.
Hi,
in case I am wrong here please direct me to the right place.
When I receive a mail with thunderbird, which contains a link in the subject, the link gets opened in my browser when clicking the Gnome notification. I would expect the email client to pop up and not the (maybe malware delivering) webpage from the link to be opened in a browser.
Best & thanks Uli
This task looks like it is about a different notification system. Please feel free to report the problem in the issue tracker of your distribution.
notification-daemon
is not under active development anymore and had its last code changes more than five years ago. Its codebase has been archived at https://gitlab.gnome.org/Archive/notification-daemon/
Closing this report as WONTFIX to reflect reality.
Translations User D-L (92d248a5) at 01 May 15:43
Update Basque translation
Looking at it again, I was mistaken: Padding between scanlines is permitted, but the final scanline needs to be minimal (i.e. no padding at the end of the file).
While this is much a smaller issue (it's easy to cut off the padding at the end before sending out the data), I still think it's an odd check, given that this isn't mentioned in the spec at all.