Version: 0.12-alpha1 (using KDE KDE 3.5.1) Installed from: Slackware Packages Compiler: gcc 3.4.5 OS: Linux I was chating with an Adium user and he mentioned that while messaging via Jabber there are some empty lines (spaces) (CRs ? \n ?) before and after my messages. This is happening only when messaging over Jabber and not occuring when messaging via other protocols. I'll post screenshots with what I (kopete) see and what he (Adium) sees.
Created attachment 14613 [details] This is what the adium user sees.
Created attachment 14614 [details] And this is what kopete user sends.
I've reprocuced the bug. By looking the debug output I can tell you it's not sending extra empty lines. "<message from="user@server/Kopete" type="chat" id="aae4a" to="user@server/Gaim" > <body>test</body> <html xmlns="http://jabber.org/protocol/xhtml-im"> <body xmlns="http://www.w3.org/1999/xhtml" style="font-family: Bitstream Vera Sans; font-weight: bold;" > <span style="font-weight:400" >test</span> </body> </html> <x xmlns="jabber:x:event"> <offline/> <composing/> <delivered/> <displayed/> </x> </message> " So it's look like a bug in libgaim(used by Adium too) while proceding XHTML body.
Ok. Then there must be an explanation why chatting with the same Adium user and me using kopete 0.11.1, 0.11.0 or 0.10.x kopete does not trigger the same bug in libgaim (always speaking for Jabber). And why the same *HTML content gets displayed correctly for other protocols (MSN, AIM) ? Ok, they are not the same protocol plugins, but it's the same simple body tag. Would there be any chance that the problem is created by some of the other tags ? There is no p tag in the transmitted xhtml but perhaps it's because some other tag was added or removed compared to what xhtml tags were transmitted by kopete 0.11.x.
> there must be an explanation why chatting with the same Adium user and > me using [old kopete] does not trigger the same bug The support of rich text in message (JEP-0071) is new in Kopete 0.12 (Before, message were just plain text) You can still disable it, i think there is a button in the toolbar to do that. So it may fix your problem. > And why the same *HTML content gets displayed correctly > for other protocols (MSN, AIM) ? Each protocols has different way for sending message. * Jabber is basically plain text, but may be XHTML for formating (according to JEP-0071) * MSN is plain text, and has metadata for colors and font * ICQ/AIM is HTML Each protocol take care to transform the message in the correct form according. > Would there be any chance that the problem is created by some of the > other tags ? Maybe it's because carriage return.
> The support of rich text in message (JEP-0071) is new in Kopete 0.12 > (Before, message were just plain text) > You can still disable it, i think there is a button in the toolbar to do that. > So it may fix your problem. Yes! That's it. Thanks very much Olivier :) I disabled rich text and the Adium/libgaim client is not receiving those Carriage Returns any more. Hmmm, now if only I could set a configuration option for globally or per protocol disabling rich text :>
*** Bug 122972 has been marked as a duplicate of this bug. ***
*** Bug 122992 has been marked as a duplicate of this bug. ***
Yeah, any hints for configuring this globally?
SVN commit 524990 by ogoffart: Fix Bug 121627: Jabber plugin sends empty lines (or CRs ?) before and after a message Removes all \n that KTextEdit add for html indentation. BUG: 121627 M +5 -1 jabberchatsession.cpp [UTF-8 ENCODING PROBLEMS] --- branches/kopete/0.12/kopete/protocols/jabber/jabberchatsession.cpp #524989:524990 @@ -251,7 +251,11 @@ JabberResource *bestResource = account()->resourcePool()->bestJabberResource(toJid); if( bestResource && bestResource->features().canXHTML() ) { - jabberMessage.setXHTMLBody ( message.escapedBody(), QString::null, message.getHtmlStyleAttribute() ); + jabberMessage.setXHTMLBody ( message.escapedBody().replace("\n","") , QString::null, message.getHtmlStyleAttribute() ); + // According to JEP-0071
*** Bug 124853 has been marked as a duplicate of this bug. ***
Hm, why this bug is marked as "resolved"? I updated to current-svn and the gaim-users still receive empty lines....
Tobias: are you using 0.11 or 0.12?
I'm using 0.12svn.
The problem is that iris use internaly QDomDocument::toString(0) which puts back the carriage returns for identation.
can we fix iris to use something else then?
*** Bug 129120 has been marked as a duplicate of this bug. ***
Someone did report the bug on libgaim list ? (as it seems more a bug in other jabber implementation, thant in kopete one, no ?)
I have reported to issue to Qt some times ago already http://www.trolltech.com/developer/task-tracker/index_html?id=118388&method=entry The solution will not be there before Qt4.2. so we can hope it will be ok in KDE4
This issue has not yet ben fixed in 0.12.4. I'm having the issue while chatting with Gaim clients. A workaround is to disable rich text formatting.
¿Is there any way to disable rich text by default in Jabber accounts?
Have the same problem here w. Kopete 0.12.4, KDE 3.5.6 7 Kubuntu Feisty. The recipient is using Gaim of Ubuntu Feisty. Still empty lines. How do I disable rich text, I don't find the button to do it.. So if this is a gaim bug has it been reported there - could someone link here?
Pidgin (=gaim) report about this: http://developer.pidgin.im/ticket/277
If it's really about Iris, how come Psi does not have this issue?
It's not about iris, but about Qt And Psi doesn't have the issue because Psi doesn't support HTML editing
*** Bug 145895 has been marked as a duplicate of this bug. ***
If anything is still considered a bug in this report I think it might have something to do with bug 140366.
*** This bug has been confirmed by popular vote. ***
Is this valid since the pidgin bug mention in comment 23 is fixed?
I can't reproduce this bug with Kopete 0.70.90 (KDE 4.2.95/Qt 4.5.1) and Pidgin 2.5.8.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.