Version: 0.7.1 (using KDE KDE 3.1.3) Installed from: Gentoo Packages When receiving an incoming message that was encrypted with GPG. The HTML tags that come with the message are not rendered, but displayed raw... Incoming Encrypted Message: <HTML><BODY BGCOLOR="#ffffff"><FONT FACE="Helvetica" ABSZ="12" SIZE="3">see you in 10</FONT></BODY></HTML>
Who is writing this message? (with what client?) Kopete encrypt only plain text messages. so it assume than the received message should be plaintext.
The client is Fire running under OS/X.
There is not realy any RFC for encyting messages. So it is difficult to say if it's Fire which is wrong, or Kopete which is wrong.
Agreed, there is no RFC for such things. However, I would submit to you you that Fire successfully encrypted a message to me using GPG. Kopete received the message... Kopete realized it was encrypted... Kopete decrypted the message... Kopete did not display the message correctly. Is it a bug in Fire to do something which may or may not be compliant with an RFC which does not exist? Or is it a bug in Kopete to do three of the four steps necessary to provide me with a plain-text version of a message? <uneducated user mode> My response is, that in light of the fact that there is no RFC, the bug is in Kopete. It is the app that cannot successfully display a message that was provided to it. Now I don't particularly care how this issue is resolved. If it needs to be resolved by talking with the Fire developers and telling them "Hey please don't do that, it breaks our code." or if it is resolved by implementing some code in Kopete to strip the tags, or if it is resolved by implementing some code in Kopete that processes those tags. My goal is to be able to easily read the message. </uneducated user mode> Fortunately I'm not an uneducated user. I'm aware that in free software, I can even fix it myself if necessary, or tell my friends and co-workers not to use the encryption feature, or any other myriad of solutions. However, one of the reasons I use KDE, is KDE seems to understand the concept of "least surprise" quite well, and quite frankly, this behaviour is surprising.
The problem is that the GPG plugin is calling setBody with plain text regardless if the incoming message is RTF or not. It should check if it is RTF via a regex and call RichText if it is.
Subject: kdenetwork/kopete/plugins/cryptography CVS commit by brunes: Check if a message matches the RTF profile before escaping it CCMAIL:63983-done@bugs.kde.org M +42 -24 cryptographyplugin.cpp 1.38 M +1 -0 cryptographyplugin.h 1.13
Subject: kdenetwork/kopete/plugins/cryptography CVS commit by ogoffart: Jason, could you please _TEST_ your patch before commiting, because it seems you didn't. And i think that your fix is not the right fix: <example>this message would break it for example</example> And since there are no RFC at all at this level, i prefer to have a full working kopete<=>kopete than a semi working for everithing. cf Bug 63983 CCMAIL: 63983@bugs.kde.org CCMAIL: jason@keirstead.org M +1 -1 cryptographyplugin.cpp 1.41 --- kdenetwork/kopete/plugins/cryptography/cryptographyplugin.cpp #1.40:1.41 @@ -153,5 +153,5 @@ void CryptographyPlugin::slotIncomingMes { //Check if this is a RTF message before escaping it - if( !isHTML.exactMatch( plainBody ) ) + if( isHTML.exactMatch( plainBody ) ) { plainBody = QStyleSheet::escape( plainBody );
This does not seems to be fixed please reopen see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408526
Kopete autodectect if the message is well formed html, otherwhise people fill complain because somme other client send html formated code. note that the html deteciton only has some tag from a whitelist (html,body,br,p,font,center,b,i,u,span,div,pre) others tag will make kopete think this is not HTML,n and so will it render as it. so in other word, this is not a bug, this is a feature :-)