Receiving notification content with invalid pango markup breaks format markup

[vilhalmer]

If the body of a notification contains something that pango considers to be invalid markup, the markup within the user-specified format will be ignored as well (see screenshot for an example). This is because we're parsing the entire formatted notification at once. This is required to have relative markup work correctly, but it could be made more robust. Here's what I propose:

• Attempt to parse the body alone using pango_parse_markup, without saving the result.
• If this reported success, continue as usual.
• Otherwise, escape the body using the existing escape_markup function before formatting.
• Parse the entire thing as we do now.

This will allow the user's format to continue working (e.g. to display the summary in bold) even when the body is unparseable. It's arguable that this isn't a mako bug, but the result of clients sending notifications that don't follow the spec. However, I've now seen this from two separate programs (including Slack), so it's probably worth putting a bandaid on.

---

An example of the < character causing parsing to fail.

cannot parse pango markup: Error on line 2 char 7: '<' is not a valid name

[emersion]

Hmm, yes, I've experienced this too. The spec allows us to advertise that we support markup, but doesn't allow clients to opt-out. :(

I think the fix you suggest is reasonable.

[progandy]

Mako should probably filter unsupported html tags as well and only keep those that are defined in the freedesktop specification. I remember that was an problem in dunst.

Well, in the current version it simply tries pango markup and strips all tags if an error occurs. It seems that was greatly simplified some time ago.

[vilhalmer]

I don't know if there's a good way to do this without accidentally ruining some notifications' content. For example, if someone sends me a message on slack that contains a tag, I don't want that tag to be removed, since it was intended as the literal text of the tag.

[progandy]

I guess in that case keep the tags for now and when a bug report is filed, add a criteria option to strip tags when receiving notifications from known bad clients.

[vilhalmer]

Hmmm, perhaps the markup criteria should be modified to only affect the received content, but always allow parsing of the markup specified in the user's format? If the user really doesn't want markup at all, they should remove the tags from the format themselves anyway.