Nested in-memory content not fully generating inside a tree.



17 years ago
4 months ago


(Reporter: murphye, Unassigned)



Firefox Tracking Flags

(Not tracked)



(4 attachments, 1 obsolete attachment)



17 years ago
I have 4 examples attached, in 4 files.

Has both an <outliner> and a <tree> that display the same rosterFile.rdf. No
problems here.

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.

Comment 1

17 years ago
Created attachment 54297 [details]

Comment 2

17 years ago
Created attachment 54298 [details]

Comment 3

17 years ago
Created attachment 54299 [details]

Comment 4

17 years ago
Created attachment 54300 [details]


17 years ago
Attachment #54298 - Attachment is obsolete: true

Comment 5

17 years ago
Created attachment 54360 [details]

Comment 6

17 years ago
Weird; I get these js errors when I try to load rosterMemory.xul:

JavaScript error: 
 line 0: uncaught exception: Permission denied to get property UnknownClass.classes

JavaScript error: 
 line 0: uncaught exception: Permission denied to create wrapper for object 

... and nothing displays.  rosterFile works as expected.

Comment 7

17 years ago
They have to be loaded from a chrome URL.

Comment 8

17 years ago
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.

Comment 9

17 years ago
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?

Comment 10

17 years ago
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.

Comment 11

17 years ago
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


17 years ago
Target Milestone: --- → Future


17 years ago

Comment 12

16 years ago
tever is not RDF QA anymore
QA Contact: tever → nobody

Comment 13

15 years ago
waterson left the building
Assignee: waterson → nobody
QA Contact: nobody → core.rdf
outliner is long-since dead.  Could we re-evaluate this bug, please?


4 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.