-
Notifications
You must be signed in to change notification settings - Fork 25
GNotifier must process the message body #24
Comments
Thanks for this discover. So as you suggested in Bug 858519, text should be filter out before passing data to libnotify. I would be very appreciated if you could propose javascript function that can do such filtering. |
I have no experience with Firefox internals but I'll do what I can. (almost a decade ago, I tried to write extensions and found the API documentation and tooling discouragingly awful. Since the Jetpack SDK came out, I haven't needed to write an extension.) I ran out of time today, but here's the partly-pseudo code I was able to come up with in the time given. (eg. No HTML sanitization yet and it just assumes that the notification daemon has the IMAGE_SVG capability when the site provides an SVG icon rather than rasterizing it) The more you can clarify what you need me to do, the more I can focus my efforts. // --== Stuff you'll probably want to call once on init ==--
var capabilities = notify_get_server_caps();
var server_info = notify_get_server_info();
var clean_markup = function(dom_node) {
// TODO: Maybe tomorrow.
};
// --== Stuff to call each time ==--
var title = title_as_provided_by_the_api;
var body_dom = dom_firefox_generates_for_internal_notification_renderer;
var icon = icon_as_provided_by_the_api;
if (capabilities.index_of('body-markup') === -1) {
// I'm too used to jQuery to write this on my own but here's the relevant bit of jQuery().text()
// http://stackoverflow.com/a/5023626
var notification = new NotifyNotification(
title,
jQuery(body_dom).text(),
icon);
} else {
var notification = new NotifyNotification(
title,
clean_markup(body_dom),
icon);
}
if (capabilities.index_of('actions') !== -1 and server_info.name !== 'notify-osd') {
// This name-matching is really how Unity's notify-osd expects you to manage its dysfunctional
// "if there are actions, show an old-style dialog" behaviour.
var actions = body_dom.querySelectorAll(
'input[type="submit"], input[type="button"], button');
for (var i = 0; i < actions.length; ++i) {
var dom_node = actions[i];
var action_id = /* Whatever code you use to reconcile DOM and GTK+ events */
var action_callback = /* Whatever code you use to reconcile DOM and GTK+ events */
notification.add_action(
action_id,
jQuery(dom_node).text(),
action_callback);
}
} Since I ran out of time before implementing it, here's what
|
As my not commenting yesterday implied, I'm a bit busy. Do you want me to wait until I can give code for (All my DOM manipulation experience is using either jQuery or the Python LXML DOM library so familiarizing myself with the W3C DOM API is a very non-trivial portion of the time it'll take.) |
I think I have enough information (from you) and can do this dirty work by myself :-) Many thanks for your involvement! |
Finally, the issue has been fixed in the latest dev xpi. It took me only 4 years! ;-) |
My tests show that GNotifier is passing through the message body verbatim. Unfortunately, notification daemons don't expect HTML and many react poorly.
(This is a common mistake people make since Pango markup borrows certain common tag names like
<b>
from HTML but is not actually HTML.)For example:
notification-daemon
reference implementation which Lubuntu 12.04 uses applies XML-style strict parsing rules and, if there's markup it doesn't recognize, it displays a blank message.<b>
,<i>
, and<u>
as literal plaintext.According to the Web Notifications spec, "The user agent must process any markup in this string so that it appears as plain text when used as a string in the underlying notification platform."
On Bug 858519 in Bugzilla, I've gone into detail on what the restrictions are and proposed an approach to performing said transformations.
The text was updated successfully, but these errors were encountered: