Version: 1.0.0 (using 4.4.2 (KDE 4.4.2), Kubuntu packages) Compiler: cc OS: Linux (i686) release 2.6.32-19-generic Since I upgraded to KDE 4.4, my chat peers are complaining that each message from me looks like this: <p>message</p> I have formatting disabled in the "Format" menu, so I would expect my message to be sent plain-text. This happens both with ICQ and Jabber peers.
I confirm. Gentoo/amd64, KDE 4.4.2, but only when OTR is active. Kopete's Format/EnableRichText is turned off. My peers didn't see it until we turned on OTR. Now they receive all my messages wrapped in <p>...</p>. Not sure if this is Kopete's bug or their clients, but I agree with disabled RichText Kopete should not send <p> tag.
I can confirm too.
same here on Arch Linux, with KDE 4.4.3
Confirming as well. I noticed it first when trying to update via identi.ca.
A bit more: when guy who gets <p>...</p> from me under OTR tried to send me XML, all tags were lost, only text nodes returned, i.e. instead of "<tag>hello</tag>" I got just "hello".
Hi, I was just investigating this issue (as I find it pretty annoying). some information about my kopete first: Version: 1.0.0 (using KDE 4.4.3 from Arch's 'extra' repository) now from what I can tell so far is that it looks like we're having two different bugs in here. the first one is the one from the original author the second one is probably the one reported by Andrea Scarpino. I found out that there's a regression in KDE 4.4.3's kopete. it is caused by this commit (thus I'm CC'ing mzanetti ;)): http://websvn.kde.org/branches/KDE/4.4/kdenetwork/kopete/plugins/otr/otrplugin.cpp?r1=1117326&r2=1117354 the issue here is that msgBody is either the parsedBody() (before KDE 4.4.1 it was the encryptedBody() of a message) I'm not 100% sure why parsedBody() returns HTML code, but anyway... unfortunately mzanetti is calling setPlainBody(msgBody) - but since the text contains <p>'s it's sent out directly to the friend you're chatting with right now. now to the second issue: I believe there's a bug in OTRPlugin::slotOutgoingMessage( Kopete::Message& msg ): why is setPlainBody/setHtmlBody being called unconditionally? there's one case where it's valid (this call should be valid: msg.setPlainBody(i18n("An error occurred while encrypting the message."));) also I think msgBody and cachedBody should be set conditionally (depending on the message's type we should call plainBody() or escapedBody()/parsedBody()) please note that I'm not 100% sure if the explanation of the second issue is 100% correct, someone with more knowledge about the otr plugin might want to take a look at it ;) Regards, Martin
Created attachment 43379 [details] possible fix a possible fix for all issues (not 100% sure about issue #1, but issue #2 should be fixed). please note that I'm NOT familiar with the OTR plugin, thus this may contain bugs use with caution ;)
Created attachment 43397 [details] Fix for OTR plugin with xml tags and opportunistic mode. (In reply to comment #7) > Created an attachment (id=43379) [details] > possible fix > > a possible fix for all issues (not 100% sure about issue #1, but issue #2 > should be fixed). > please note that I'm NOT familiar with the OTR plugin, thus this may contain > bugs > Thanks for your investigations. Unfortunately while your patch has a good approach, it doesn't seem to fix this here but additionally breaks other things. Using your patch as input I have investiged a little further and hope to have produced something usable now. The attached patch should fix all issues with <p> tags. However, it definitely breaks OTR opportunistic mode if the user enables rich text formatting. I see no way to support both with current kopete and libotr. Instead, this fix tries to have opportunistic mode working for plaintext messages, but have working rich text if the user wants that (at the cost of broken opportunistic mode). Note: RTF with jabber seems to be badly broken here also if the OTR plugin is completely disabled... It would be nice if some of you could test this with other protocols too. Here is a little check list what to test: - Are messages sent out correctly (no <p> tags etc)? - Are user-typed tags and special chars handled and delivered corectly (no lost characters or tags like <,>,ä,ö,&,? etc.)? - Is an OTR session automatically established if both clients have opportunistic mode enabled? - Is Rich Text Formating working? If no furher problems with this patch are reported, I will commit it before 4.4.4. Thanks
> If no furher problems with this patch are reported, I will commit it before > 4.4.4. I'm using a patched (with your patch) kopete for three days now and I can confirm that the <p> bug is gone :) I could not find any new issues - so it looks stable. broken opportunistic mode for RTF messages is unfortunate but still better than the old bug. maybe you could open another ticket with some more information what one would need to do to get opportunistic support for RTF messages?
*** Bug 236419 has been marked as a duplicate of this bug. ***
SVN commit 1130163 by mzanetti: fix handling of xml tags in tagged plaintext messages. This, however breaks opportunistic mode when rich text formatting is enabled. Currently there seems to be no way to support both at the same time. The current solutions seems to be most useful one. BUG: 233330 M +1 -1 otrlchatinterface.cpp M +45 -6 otrplugin.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1130163
*** Bug 240368 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
*** Bug 237023 has been marked as a duplicate of this bug. ***
*** Bug 242700 has been marked as a duplicate of this bug. ***
*** Bug 242596 has been marked as a duplicate of this bug. ***
*** Bug 240596 has been marked as a duplicate of this bug. ***