I have 4 examples attached, in 4 files. rosterFile.xul: Has both an <outliner> and a <tree> that display the same rosterFile.rdf. No problems here. rosterMemory.xul: This creates the same data as in rosterFile.rdf, but only in-memory. See the code in rosterMemory.js for this. The <outliner> is built correct, but only the first level of content is displayed inside the <tree>. Now, both <tree>s in the XUL files are exactly the same, except for the datasources. For some reason, the file fills out the whole tree, but the in-memory datasource does not. Expected Results: All 4 templated generate same content. Actual Results: The <tree> in rosterMemory.xul does not display all the in-memory content. It only displays the first level. The other 3 are working correctly. I am setting as a blocker, because a new Jabberzilla release cannot happen until this is fixed. From our perspective, this is urgent.
They have to be loaded from a chrome URL.
Weird, somehow I had gotten the impression that resource:/chrome/... would work as well. Oh, how I hate chrome. Anyways, I see the problem now.
Ok, after looking that the NSPR InMemoryDataSource:5 and nsXULTemplateBuilder:5 logs for a bit, I figured out what's going wrong. Whenever I tried to expand [+] in the in-memory tree, I saw stuff like this: nsRDFPropertyTestNode[834aed8]: FilterInstantiations() source=[chrome://jtest/content/rosterMemory.xul#Jabberzilla] target=[(unbound)] This was failing, because the datasource has no assertions about |chrome://jtest/content/rosterMemory.xul#Jabberzilla|, only about |Jabberzilla|. When the rdf is loaded from a file, the base uri is presumably set from the file uri -- for the in-memory datasource, there is none. I was able to work around this by changing setGroup() in rosterMemory.js slightly: - var groupResource = this.roster.rdf.GetResource(group); + var tmpuri = "chrome://jtest/content/rosterMemory.xul#" + group; + var groupResource = this.roster.rdf.GetResource(tmpuri); There's probably an API somewhere that will let you set the base uri, which should work as well (sorry, I'm a dummy when it comes to using this stuff). However, this does seem like a bug in the <tree> code, or at least an inconsistency. The xul log when I open the outliner [+] shows that FilterInstantiations is called on just |Jabberzilla| -- something in the tree code is prepending this unecessary base uri. The question is, will the fix break anything else?
The difference appears to be in the use of nsXULContentUtils::GetElementRefResource, which uses nsXULContentUtils::MakeElementURI to generate absolute uris for xul elements (it does this by prepending the document base url to every id that doesn't include a ':'). The nsXULOutlinerBuilder appears to use GetElementRefResource once, on the root element; the nsXULContentBuilder uses it everywhere. Stubbing MakeElementURI to not prepend docURL fixes this, but I need a more thorough understanding of the code before I actually propose that.
I verified that the work-around works :-) Thanks man! I remember thinking about trying this, but then I forgot to it before submitting the bug. This is good enough for me to continue on with Jabberzilla development, setting as major though, because it needs to be fixed before 1.0.
Severity: blocker → major
tever is not RDF QA anymore
QA Contact: tever → nobody
waterson left the building
Assignee: waterson → nobody
Status: ASSIGNED → NEW
QA Contact: nobody → core.rdf
outliner is long-since dead. Could we re-evaluate this bug, please?
You need to log in before you can comment on or make changes to this bug.