GNOME Bugzilla – Bug 649277
Banshee's notifications use non-standard tags
Last modified: 2011-11-15 19:02:26 UTC
Created attachment 187123 [details] Sample notification According to this downstream report : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588999 , this is related to Banshee using non-standard markup for notifications. As a result, markup such as <span> show up in the notification bubble, making it unpleasant to see and difficult to read.
Based on a similar report, it looks like this is an issue with the notification system, not Banshee, so I'm closing this report. *** This bug has been marked as a duplicate of bug 650314 ***
I'm afraid the conclusion in bug 650314 is wrong. This is not about a typo, or a problem with xfce4-notifyd. Banshee is generating <span> tags, and those are simply not allowed according to the standard: http://www.galago-project.org/specs/notification/0.9/x161.html In other words, it's not actually HTML -- it's a very limited number of tags, and <span> isn't one of them. I assume some notification daemons support more tags, and that's what the banshee developers use, but those are not standard. If applications generate non-standard tags it's no surprise that those applications are going to break on systems that are merely standards compliant.
Thanks for the clarification (and the link to the spec). While it's less than ideal that Xfce mangles tags it doesn't recognize, it's true that Banshee should avoid using the <span> tag altogether, so I'm reopening and confirming this. Next up, trying to think of the best fix for this... It looks like Banshee is currently trying to change font size and color like this: <span color="value" size="value"></span>. In normal html, spans don't have color or size attributes -- do any notification daemons support this? Is this actually accomplishing anything? If so, could we instead do something like <i color="value" size="value"> ? Since <i> is a recognized tag, hopefully this wouldn't break Xfce's notifications, but it could still change color and size as needed with notification systems that support that sort of thing. Anyway, just speculating -- I'll have to play around with this when I get home.
*** Bug 650314 has been marked as a duplicate of this bug. ***
If my tests are correct and I understand the sourcecode of xfce's notification daemon, the only markups they support yet are. <b>,<i>,<u>,<a href="">,<img href="" alt="">, all others were printed as normal text (with a typo in the closing tag) As long as there is no span-tag supported or unsupported tags were just ignored, I see no other solution than banshee restricts his notification on these markups.
*** Bug 655747 has been marked as a duplicate of this bug. ***
*** Bug 661675 has been marked as a duplicate of this bug. ***
*** Bug 661771 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > simply not allowed according to the standard: > > http://www.galago-project.org/specs/notification/0.9/x161.html GNOME's standard is actually defined here: http://developer.gnome.org/notification-spec/
Created attachment 199127 [details] notification in gnome 3.2
Created attachment 199128 [details] [review] patch Solved the problem by using <i> tags instead of spans.
Created attachment 199398 [details] [review] gnome3-notification.patch Remove unused code.
Created attachment 199399 [details] [review] gnome3-notification.patch Just realized also don't need String.Format either.
Review of attachment 199399 [details] [review]: Thanks for the patch Travis, I committed it in git master : http://git.gnome.org/browse/banshee/commit/?id=6c9a3fde In the future, it'd be helpful if you could use "git format-patch" to produce the patch. See this page for more info : http://banshee.fm/contribute/write-code/
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
*** Bug 663005 has been marked as a duplicate of this bug. ***
*** Bug 663201 has been marked as a duplicate of this bug. ***
*** Bug 664135 has been marked as a duplicate of this bug. ***