| Summary: | WebKit renders an empty view when fed text/plain which contains 0x00 characters | ||
|---|---|---|---|
| Product: | [Unmaintained] trojita | Reporter: | Jan Kundrát <jkt> |
| Component: | Desktop GUI | Assignee: | Trojita default assignee <trojita-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | git | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/trojita/14efb142be63e7a25542ea09ad571ca320eaec16 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | The "text/plain" attachment which contains zero bytes msg_2282_1 | ||
Git commit 653e02203abe1211780633e962835827219a52dc by Jan Kundrát. Committed on 15/06/2013 at 00:15. Pushed by jkt into branch 'master'. When decoding from unknown encoding and assuming UTF-8, be sure to not stop at first NULL byte This does *not* fix #321160 (this code is not even triggered in this situation), but it's a sane thing to do anyway. I guess that the code shall be audited for other instances where we might silently truncate the data here; it's caused by an implicit conversion from QByteArray to uchar*. M +1 -1 src/Imap/Encoders.cpp http://commits.kde.org/trojita/653e02203abe1211780633e962835827219a52dc Git commit 14efb142be63e7a25542ea09ad571ca320eaec16 by Jan Kundrát. Committed on 15/06/2013 at 00:23. Pushed by jkt into branch 'master'. WebKit: convert plaintext input with NULL bytes without silent truncation This does *not* fix HTML input containing null bytes. I don't know if this problem is relevant for HTML e-mails as well. REVIEW: 111030 M +10 -1 src/Gui/SimplePartWidget.cpp http://commits.kde.org/trojita/14efb142be63e7a25542ea09ad571ca320eaec16 |
Created attachment 80517 [details] The "text/plain" attachment which contains zero bytes msg_2282_1 The SimplePartWidget renders an empty page instead of the actual content when fed with the test data (a real-world example from the kdepim ML). The only "weird thing" I recognize in there are the null bytes within the contents, but I have no proof that this is what is causing troubles here.