When I create an empty container in the InMemoryDataSource or through RDF/XML, the xul template builder does not recognize that it is a container and sets the container property to false. This happens because the template relies on nsIRDFDataSource::ArcLabelsOut semantics which are not supported for those datasources. According to the xul template reference, it appears the solution is to change the implementation of the ArcLabelsOut function. I may be able to this for my own datasource, but I don't see how that is a practical solution in general. I am also seeing a number of problems using the simplified treecell syntax (setting value="something"), even after I add contents to my container. I'm guessing here, with no real evidence, but I think something is having trouble with the transition from container="false" to container="true". To see this, put the following into a file named emptyContainer.rdf, in a bin/bugs subdirectory: <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Seq about="NC:EmptyContainerContainer"> <rdf:li> <rdf:Seq about="NC:EmptyContainer"> <!-- Look! I'm an empty container! --> <!-- XXX ---> </rdf:Seq> </rdf:li> </rdf:Seq> </rdf:RDF> Now display with the following xul: <?xml version="1.0"?> <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <window xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <tree datasources="resource:/bugs/emptyContainer.rdf" ref="NC:EmptyContainerContainer" flex="1"> <template> <rule iscontainer="true"> <treechildren> <treeitem uri="..."> <treerow> <treecell indent="true" value="Bucket"/> </treerow> </treeitem> </treechildren> </rule> <rule> <treechildren> <treeitem uri="..."> <treerow> <treecell indent="true" value="Apple"/> </treerow> </treeitem> </treechildren> </rule> </template> <treecol/> </tree> </window> Notice that the word "Apple" appears. I believe you should see "Bucket". Add the following to the rdf file, where the XXX comment appears, and you will: <rdf:li> <rdf:Description/> </rdf:li>
reassigning to waterson for triage
I think the answer here is perhaps to mark "NC:EmptyContainer" as "#instanceOf" "#container" in the RDF file, and in the template builder when deciding whether an item is a container or not, check for that arc triplet along with the other checks we do.
bulldozer to M12
spam: changing qa contact from ckritzer -> paulmac for xul bugs
*** Bug 20590 has been marked as a duplicate of this bug. ***
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
*** Bug 29777 has been marked as a duplicate of this bug. ***
cc'ing myself. this seems to be the bug that addresses the 'can't paste/drag/add items in any way to rdf folders that are empty' problem.
Summary: container == false for emtpy RDF containers in RDF/XML or InMemoryDataSource → container == false for empty RDF containers in RDF/XML or InMemoryDataSource
*** Bug 33031 has been marked as a duplicate of this bug. ***
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
*** Bug 35461 has been marked as a duplicate of this bug. ***
This WORKSFORME (I see "bucket"), if the comment lines are removed from the sample RDF file: <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Seq about="NC:EmptyContainerContainer"> <rdf:li> <rdf:Seq about="NC:EmptyContainer"> </rdf:Seq> </rdf:li> </rdf:Seq> </rdf:RDF> I get well-formedness exception from expat otherwise: XML Error in file 'file:///d:/bugs/14449.rdf', Line Number: 10, Col Number: 19, Description: not well-formed Source Line: <!-- XXX --->
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
N.B. that the template builder code has been whacked quite impressively over the last six months, so I'm not sure when this *really* got fixed :-). Man, six months. Sorry it took so long.
I just filed a new bug for this <A HREF="show_bug.cgi?id=36184">(bug 36184)</A> but firstname.lastname@example.org pointed out the duplication. This bug seems to have shown up multiple times in the specific case of bookmark editing. Here are some useful bits from my other report: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m15) BuildID: 2000041705 Reproducible: Always Steps to Reproduce: 1.open Manage Bookmarks dialogue 2.create new bookmark folder 3.drag bookmark into new folder Actual Results: bookmark appears as a peer of the folder Expected Results: bookmark should appear inside folder
*** Bug 36184 has been marked as a duplicate of this bug. ***
No, I think they're different bugs. rjc: could you read the above and let me know?
reopening as this still happens with 2000041809 builds (never saw it work actually)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This really does work, I swear. :-) You could verify this by copying-and-pasting the stuff below into separate .xul and .rdf files, but since I've already done that, I'll just attach them to the bug for ya...
To verify, save the above files to your hard drive in the same directory, and then open using "file->open".
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
ummm so this works brightly, brightly and with beauty on all platforms with the 2000041909 builds. Just to make sure i wasn't crazy I went back and checked and it definitely didn't work with the 2000041809 build, btw. Marking VERIFIED
Status: RESOLVED → VERIFIED
*** Bug 40276 has been marked as a duplicate of this bug. ***
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.