460961 - rdf natural sort not respected

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[Christian Pernot]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3
Build Identifier: Mozilla XULRunner 1.9.0.3 - 2008092518

Hello,

we are migrating an XUL application from 1.8.1 to 1.9.

we build many xul elements with rdf datasources with 3-4 depth levels.

I have strange result in some case: I don't precise any sorting, so the elements should be in the order they come in RDF, but still, the first element comes in the last position. (the RDF order is OK)


Reproducible: Always

Steps to Reproduce:
1.Go to the URL
2.See order in the first box 
3.Order should be 12345
Actual Results:  
order is 2-3-4-5-1

Expected Results:  
1-2-3-4-5

the same test with firefox2 works as it should.

Comment 1

[Axel Hecht]

This is a XUL templates bug, I assume, moving it over there.

Comment 2

[Christian Pernot]

I found that using only complete template syntax, or only simple template syntax works : http://pingroom.net/test/test_template_order_works.xul

it's the mixing of the two that makes the problem to appear.

Comment 3

[Daniel Veditz [:dveditz]]

This doesn't fit the criteria for our branch security/stability releases. You'll want this fixed on trunk for the upcoming 3.1. Getting it confirmed will be a good first step to gain visibility with the developers. See the support forums at http://support.mozilla.com if you need help with that.

Comment 4

[Christian Pernot]

it still doesn't work well, even with only complete syntax.
I have a big template, with 17 rules inside (nested), and the order is still not the natural order from the RDF.

Any workaround please? it's a major problem for our application

Comment 5

[Christian Pernot]

tested with latest firefox nightly (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081111 Minefield/3.1b2pre).

the bug is still there. For me it's blocking, it's not only visual, but it's a regression, which makes our application not usable (I suppose we're not the only one).

Comment 6

[Martijn Wargers (dead)]

This regressed between 2008-07-13 and 2008-07-14:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-13+04&maxdate=2006-07-14+06&cvsroot=%2Fcvsroot
I bet a regression from bug 335122.

Comment 7

[Martijn Wargers (dead)]

There is also a problem where on first load, nothing of the results show up at all, only after a reload.
This regressed between 2006-02-13 and 2006-02-14:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-02-13+06&maxdate=2006-02-14+07&cvsroot=%2Fcvsroot
I guess that's a regression from bug 285631.

Comment 8

[Martijn Wargers (dead)]

Attachment: template attached to the bug

Comment 9

[Martijn Wargers (dead)]

Attachment: testcase attached to the bug

Comment 10

[Boris Zbarsky [:bzbarsky]]

Neil, can you please take a look at this?

Comment 11

[Neil Deakin]

You need to specify the same container variable for all rules. Templates only scan the first rule to determine what this variable is, and simple rules default to using ?uri. Either you need to use <content uri="?uri" ...> in all rules or set the variable explicity using <template container="?medias">.

This causes both the mixing of simple and full rules issue as well as the sorting issue.

Comment 12

[Christian Pernot]

Thank you so much. 
I suppose we were lucky that it worked with previous versions.

Comment 13

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336