Menu
▾
▴
#149 Extra line breaks
I seem to get extra line breaks in conversations with people using the standard MS 2007 OCS client. It looks like it's inserting a line break after about 80 characters. Outgoing messages from me don't have this issue.
Version 1.11.2, Win7, Pidgin 2.7.7
Related
Forums: New lines sent in Lync show up as one line in Pidgin
Forums: New lines sent in Lync show up as one line in Pidgin
This seems to be an incorrect setting on the M$ client on the remote side. I have only seen it for one person myself, all other M$ client user send "correct" IMs. I think I looked into the log for that person once and if I remember correctly the extra line was hard-coded in the HTML text we receive.
Unless you can provide a log proving otherwise, I'll close this bug as invalid.
I see it for all my contacts, but that doesn't mean it's not a setting that they all have - I'm capturing a debug log now (I'm getting 3061972), so I'm trying to see if anything useful shows up) so if I see anything that proves otherwise, I'll let you know.
Log showing a message with added line breaks
I have attached a log that shows some extra line breaks. All of the messages that I recieve are similar to this, in that the messages contain line breaks (^M) and BR/P tags. It looks like the protocol might use BR and P tags for line breaks, so it might be possible to ignore the extra line breaks, and use the tags instead. But then I'm sure you guys know the protocol better than I do. So feel free to mark this as invalid, I'm just happy that I don't have to use communicator any more.
Thanks for the log. Where do the extra line breaks appear? E.g. your log shows
the sentence matters? does the length of the sentence matters? does the length
^M
of the sentence matters? does the length of the sentence matters? does the
Does the line break appear between the words "the length" and "of the sentence"?
As you can see form the log, pidgin-sipe simply extracts the HTML from the message (from <DIV> to </DIV>) and forwards it straight to libpurple. Pidgin then renders the HTML. The "^M" in the middle of the text SHOULD NOT cause line breaks, because they should be considered simple white space by the HTML renderer.
We of course can't prevent (possible) line breaks caused by <BR>,</P> and </DIV> . Those are under the control of the HTML renderer.
Screenshot of my pidgin log showing where line breaks occur.
The line breaks are appearing where the ^M's appear in the log; that's why I thought that those were being interpreted by newlines - the BR and P tags seem to be rendered correctly. I've attached a screenshot of the log file - interestingly, the log rendered *correctly* for the message sent from the contact, but I had copy/pasted what I received back to him, and that still shows where the line breaks occurred. So the image is from the log, not "live" from the debug.log.
Thanks for the picture. IMHO that is definitely incorrect, LF and CR should be considered white space in HTML.
I'll try to look into this maybe this evening. I hope you are able to build the code from git to test it?
I should have the requisite knowledge to build from git, but I'm not set up to do so yet - I'll try to get an environment set up tonight/tomorrow to build (but may not be able to test until Monday depending on whether people are working this weekend). Thanks!
Please try git commit 88d9202. We now strip out \r & \n from text/html messages.
In my preliminary tests I didn't see any problems, but this surely needs a lot of testing in different situations.
I was able to get the plugin built tonight (that was... interesting), and a quick test looks ok - I'll be able to give it a good workout on Monday when people are back at work. Thanks for the quick turnaround!
After moderate usage this morning, it looks like the extra line breaks are gone. Thanks!
I tested it with the one user I had the problem with previously and couldn't reproduce it any more. The log doesn't show "\r" in his case but maybe something has changed in the meantime.
Closing.