276376 - Ignoring newlines inside pre element in description

Status: RESOLVED WORKSFORME

(MailNews Core :: Feed Reader, defect)

Description

[Zbynek Winkler]

The description field contains escaped html. TB recognizes this and changes font
for <pre> element but it does not respect the embeded newlines so each <pre>
element displays as one really long line.

Comment 1

[Zbynek Winkler]

(In reply to comment #0)
I forgot to mention that I am using View > Message Body As > Simple HTML to view
the description (the option to view the description or the webpage seems broken
somehow - see bug 259018).

Comment 2

[Mike Cowperthwaite]

I think see this also with this feed:
  http://thedailywtf.com/Rss.aspx
My subscription is set up with "show page summary instead of loading page"
turned ON.  Not all items from the feed use a <pre>, some use an image to show 
the code snippets being displayed.

I don't think the entire summary of the page really needs to be on a single 
line; but in the case of the <pre> blocks, it's interfering.

Reporter: I'm not sure what the "description field" is in your bug report; if my 
description of the problem is different from what you're seeing, please provide 
more detail.  I see the same results with "as Original HTML" and "as Simple 
HTML."

Comment 3

[Mike Cowperthwaite]

Actually, I've gone back and loaded the feed directly into the browser -- it 
appears that the line breaks are not being included in the XML stream.  Now I 
think it's up to the stream to insert <br> tags into the <pre> block.

Comment 4

[Zbynek Winkler]

I double checked the feed I have supplied and it does contain the line breaks.

By description I meant rss > channel > item > description element.

I double checked the View > Message Body As and it seems to have some effect
only on items that are not in cache. When I switch to Original and select
message not already downloaded I get the web page. I do not know if this is a
feature or bug. Another check revealed that it sometimes has effect sometimes not :(

Comment 5

[Mike Cowperthwaite]

Attachment: Feed from URL as file

(In reply to comment #4)
> I double checked the feed I have supplied and it does contain the line
breaks.

You looked at the feed itself, or at the associated web page?  I looked at that
same feed in Firefox and the XML data's <Description> tag has only one line
break -- in the middle of the word "const"; see attached file.

Also, if I recall correctly, line breaks in any portion of an XML data stream
can be ignored, unless the text is enclosed in a <![CDATA[....]]> block.

Comment 6

[Zbynek Winkler]

(In reply to comment #5)
> You looked at the feed itself, or at the associated web page?  I looked at 
> that
> same feed in Firefox and the XML data's <Description> tag has only one line
> break -- in the middle of the word "const"; see attached file.
>
I looked at the feed in Firefox in View > Page Source. The line breaks seem to
be there even in the attached file. I also checked in vim.

> Also, if I recall correctly, line breaks in any portion of an XML data stream
> can be ignored, unless the text is enclosed in a <![CDATA[....]]> block.  
>
Ok, I didn't know that. But it does not work anyway :(. I tried to enclose the
text in <![CDATA[...]]> but the newlines are eaten away nevertheless.

It is interesting to note that the newlines are not available in Thunderbird
View > Message Source (it is one long line there) so something got rid of them
along the way.

Comment 7

[Mike Cowperthwaite]

(In reply to comment #6)
> I looked at the feed in Firefox in View > Page Source. The line breaks seem to
> be there even in the attached file. I also checked in vim.

Yes, you are correct; my mistake.


> > Also, if I recall correctly, line breaks in any portion of an XML data
> > stream can be ignored, unless the text is enclosed in a <![CDATA[....]]>
> > block.  
> >
> Ok, I didn't know that. But it does not work anyway :(. I tried to enclose the
> text in <![CDATA[...]]> but the newlines are eaten away nevertheless.

I may be mistaken here as well.  My reference is XML In a Nutshell; it says 
everything in the block is "raw character data" -- but it doesn't say anything 
specific about whitespace or newlines.  The stated advantage to CDATA is that it 
prevents you from having to subsitute the lt/gt/amp entities for <>&.

Comment 8

[Avi Kivity]

An additional url showing the problem is 
 
  http://fedoraproject.org/infofeed/inputs/rawhide.xml 
 
the feed contains newlines in the description field (verified with wget), yet 
renders as one long line. 

Comment 9

[alta88]

this no longer valid it seems.  linebreaks in the <pre> tag are certainly there using Tb24, in all 3 view render modes, when subscribing to the attached file link.