I send a notification via:
notify-send Test "<span style=\"color:red;\">test</span>"
What I receive in the notification-pop-up is this:
As you can see the closing span-Tag has a typo (>/span> instead of </span>)
I'm using xfce4.8 with xfce-notifyd 0.2.1 under ArchLinux.
Other users reported they cannot confirm the behavior under gnome. So it seems to be a problem with xfce and not libnotify.
I found a hint. In xfce-notify-window.c there is a function called xfce_notify_window_validate_escape_markup
First I don't understand why this function is neccessary.
It seems to look whether a string contains markup.
In the part where it checkes whether it's a closing tag, it seems that a "<" is replaced by ">" if the markup-tag is not b,i,u or a. (Line 867)
1. Should'nt it be "<".
2. Why is it neccessary to make a markup check? Isn't this done by libnotify?
(Sry, if I write something completly stupid. I'm a beginner in solving bugs ;) )
I noticed now that notifyd just handle <b>,<i>,<u>,<img> and <a> tags.
So I would suggest, that in the future notifyd extract unhandled markups. So programmer have still the possibility to uses e.g. <span> for those notification-daemons which can handle it, but users who uses xfce are not confronted with the markup.
First, I would like to thank you for your very accurate bug report. I just fixed the invalid markup escaping in the git branch (commit f7b96e45e18e794ea834858e2290af7aafec6b21).
According to the Freedesktop specification which describes what a notification should implement and what clients can expect, the only valid tags are b, i, u, a and img. "span" and other friends are not to be used by clients.
Unfortunately, notification-daemon implements the markup parsing with using pango markup which allows much more possibilities and a lot of clients tend to abuse this.
I personally prefer to stick to the specification in this case as the allowed tags already offer a fine degree of customization. Though, I agree that our markup escaping code could use some simplification and would be pleased to provide help and to review patches if you are willing to work on that.
Ignoring unexpected markup could be a could idea but still showing it is a way to have clients respect the specification.
I'll leave this bug open for discussion but the bug seems fixed as far as I'm concerned.
The code now uses g_markup_escape_text which fixes the issue you had and reduces maintaince. Marking this as fixed.