324179 - RSS2 and Atom parsers picking up elements at wrong nesting level

Status: RESOLVED FIXED

(MailNews Core :: Feed Reader, defect)

Description

[James Snell]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

In atom:entry elements that contain a source element, if the source element contains an alternate link, e.g. <entry>...<source><link href="source_url" /></source><link href="entry_url" /></entry>, Thunderbird is picking up the source element's alternate link as the alternate link for the entry if the source element appears before the entries alternate link.

Reproducible: Always

Steps to Reproduce:
Create a feed whose entries have <source> elements containing alternate links where the <source> element appears before the entries own alternate link.

Actual Results:  
Thunderbird displayed the source alternate link as the URL for the entry

Expected Results:  
Displayed the alternate link for the entry, ignoring the source alternate

Comment 1

[Robert Sayre]

Got a testcase handy, James?

Comment 2

[Robert Sayre]

After reviewing, I'm going to set this back to major. This bug shows a general issue with our use of getElementsByTagNameNS in RSS2 and Atom. We could get burned by Microsoft RSS extensions and other things as well.

Comment 3

[James Snell]

Test case is available at http://www.snellspace.com/public/sourcetest.xml

Note that the problem affects more than just the link element. Title, Updated, etc are also affected.

Comment 4

[Robert Sayre]

Attachment: use a local method to filter out nodes deeper in the tree

Comment 5

[Scott MacGregor]

fixed on the trunk and the thunderbird 2.0 branch. 

I didn't think this was severe enough to go into the security/stability update (1.5.0.x), lemme know if you disagree.

Comment 6

[James Snell]

It is possible to work around the current problem* by moving the source element around in the atom:entry element so from that point of view only, it's not a critical for 1.5.x.  Regardless, I would highly recommend this to go into the stability update for 1.5.x given that it is not yet clear how this could impact the use of feeds with extension elements that reuse core atom elements.

* I've already modified by app to account for this problem and our feeds are rendering properly in Thunderbird 1.5.

Comment 7

[Robert Sayre]

(In reply to comment #5)
> fixed on the trunk and the thunderbird 2.0 branch. 
> 
> I didn't think this was severe enough to go into the security/stability update
> (1.5.0.x), lemme know if you disagree.

Fully agree. Since it's never been reported by a user, only in a test suite, there is no upside to the risk of regression.

Comment 8

[James Snell]

Minor nit: the error was first reported to me by a user of a deployed application; a test suite was used to validate the error.  Regardless, it's easy to work around. I'll document the workaround on my blog and call it a day.  Thanks for taking a look and getting this fixed.

Comment 9

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.3 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 ID:2007032620 -