Automatically escape angle brackets that are not part of the supported tags

[anbenson]

I have a notification where the summary reads something like: July 2017 <3 (For context, it's the title of a chat in Facebook Messenger, and the <3 is rendered as a heart emoji inside Messenger.)

My dunstrc's format is: format = "<b>%s</b>\n%b" so that the "formatted" field that gets parsed is: formatted: '<b>July 2017 <3</b> Some message text here'

Dunst is giving me the error "Error parsing markup: Error on line 1 char 50: '3>' is not a valid name" (char 50 because I removed some identifying information for privacy). So it seems to think that the "<3" is a tag of sorts, but it really isn't.

I'm not familiar enough with the internals of dunst to suggest a good elegant solution, but could we fix this? I don't think it's Facebook Messenger's job to escape the <, as far as I know.

I'm running dunst v1.2.0 on Arch Linux (I think the bug still exists on the most recent commit, but I'm not sure). Let me know if you need more information.

[tsipinakis]

This has been a longstanding issue and many workarounds have been implemented

I'm not familiar enough with the internals of dunst to suggest a good elegant solution, but could we fix this? I don't think it's Facebook Messenger's job to escape the <, as far as I know.

The notification spec does not say who's responsibility it is to escape markup, but since it defines some HTML tags that can be parsed I'd assume it's the clients job to escape items (how can dunst know what's a tag and what's not?).

That said the markup setting can help here: If you're not using markup at all you can just set it to no and disable it entirely, if not you can set up a rule as follows

[messenger]
appname = "Facebook Messenger"
markup = no

to disable markup just for that app.

I'd love to have some more intelligent markup handling but it's in the low priority list since many of the other notification daemons also suggest escaping HTML characters (<, >, &).

[anbenson]

I agree that it makes sense that it's the client's job to escape stuff from my limited knowledge of how libnotify and dunst work. But it seems that the tags that are allowed are very limited - 10 of them, it seems like. Can we do an initial pass to escape any angle brackets that aren't part of one of the 10 allowed tags?

[tsipinakis]

Can we do an initial pass to escape any angle brackets that aren't part of one of the 10 allowed tags?

I'll change the scope of the issue to this, I think it's a good idea but as said in the low priority for now. A PR is welcome if anyone wants to pick it up.

[anbenson]

I've just noticed that this bug is reproducible on master, but not on v1.1 specifically ad2aef6. It's worth a look to see what we did before. If I have time I can investigate and maybe make a PR.

[anbenson]

Actually it looks like it escapes all angle brackets regardless of my markup settings, looks like something that was fixed since.

[bebehei]

According to a git bisect if found this commit to be the bad one: 4e1b97f3ccc35672d5588be1b4f801b3532358c6