tdlib-purple
tdlib-purple copied to clipboard
ars3niy
Filenames in pidgin are escaped twice
I received a file named something like Hello World.pdf (I can't share the actual name :/)
The file has been saved to /home/user/.purple/tdlib/+49123456789012/documents/Hello World.pdf, and that's correct. (Although I would feel more comfortable with /home/user/.purple/tdlib/+49123456789012/documents/Hello%20World.pdf, as that makes it obvious that there's no way to do WeirdStuff™.)
When I click the link in pidgin, the browser tries to open the location file:///home/user/.purple/tdlib/+49123456789012/documents/Hello%2520World.pdf, which gets interpreted as the file /home/user/.purple/tdlib/+49123456789012/documents/Hello%20World.pdf, but that file does not exist.
Note that %20 would be the encoding of the space character ( ), so this strongly smells like double-html-escaping.
This should be a problem with desktop environment, rather than the plugin. Are you using KDE or gnome?
Looked further, and turns out if you're using neither GNOME nor KDE, it won't show some silly dialog as I first thought, but rather use run a browser by other means. Still, the problem could be anywhere.
I think I see a bug in pidgin. It occurs when neither GNOME nor KDE is used (or in my case, I can reproduce it when using KDE with konqueror package uninstalled, which removes kfmclient).
My "bug report" is here https://lists.pidgin.im/pipermail/support/2020-August/thread.html
I'm using pidgin on Xfce.
I guess pidgin uses the "browser" setting to determine what to do with it. The above behavior happens when it's set to "Firefox"; I don't remember whether that's the default.
If I set it to "Manual", and use xdg-open %s, (because I can intercept that more easily by just injecting something in the $PATH), then I can see the call that opens it:
xdg-open /home/user/.purple/tdlib/+49123456789012/documents/Hello%20World.pdf
To spell it out: This is wrong. It should be either file:///something/Hello%20World.pdf, or /something/Hello World.pdf.
This means that the issue occurs before pidgin calls a new process. So it's not the operating system's or desktop environment's fault.
(Note that setting the "Browser" to firefox file://%s is not a workaround, as this breaks literally all other links.)