You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At first I thought I would just extend the list, but it seems like a small step and maybe a bigger solution is ideal. It seems that K9 is using a full browser engine to render the mail so it should be possible to input any HTML. This is just like how Thunderbird desktop works. I don't think there is any major issue with this approach. The whitelist already allows any CSS so there is little more that can be done. I guess <video>, <audio>, <object> and <iframe> may be interesting. But Ideally those would be implemented with a generic block on remote content. (Actually it would be nice if <video> and <audio> were allowed, if not automatically when clicking at least when remote-content is enabled).
The text was updated successfully, but these errors were encountered:
Checklist
App version
6.801
Problem you are trying to solve
I am trying to read an email that uses "advanced" HTML features.
Suggested solution
K9 should allow basically all HTML. Presumably only the following should be blocked:
This would allow email authors to better control the formatting and provide a better reading experience.
Screenshots / Drawings / Technical details
I originally noticed this issue because I wasn't seeing some expected padding. I eventually figured that this was because it was applied on an
<article>
element and K9 uses a whitelist (https://github.com/thunderbird/thunderbird-android/blob/main/library/html-cleaner/src/main/kotlin/app/k9mail/html/cleaner/BodyCleaner.kt). (I assume, I haven't read the source too closely.)At first I thought I would just extend the list, but it seems like a small step and maybe a bigger solution is ideal. It seems that K9 is using a full browser engine to render the mail so it should be possible to input any HTML. This is just like how Thunderbird desktop works. I don't think there is any major issue with this approach. The whitelist already allows any CSS so there is little more that can be done. I guess
<video>
,<audio>
,<object>
and<iframe>
may be interesting. But Ideally those would be implemented with a generic block on remote content. (Actually it would be nice if<video>
and<audio>
were allowed, if not automatically when clicking at least when remote-content is enabled).The text was updated successfully, but these errors were encountered: