I have some problems creating content with XUL templates, specifically with containment. This problem shows up in many places in messenger: - the Move and Copy menus - very often the menu items won't show up until you pull the menu down a number of times. - The "<html:select>" widget in the New Folder dialog - you only get the toplevel list of servers, no subfolders - trees with the persist="open" option, or add open="true" to your treeitems (bug #13252) Here's an example of what we're trying to do (from the new folder dialog) <html:select id="selectedparentfolder" datasources="rdf:msgaccountmanager rdf:mailnewsfolders" ref="msgaccounts:/"> <template> <html:option uri="..." value="..."> <text value="rdf:http://home.netscape.com/NC-rdf#Name"/> </html:option> </template> </html:select> What you end up seeing is +---------+-+ | server1 |V| +---------+-+ | server1 | | server2 | | server3 | +-----------+ but I expected +---------+-+ | server1 |V| +---------+-+ | server1 | | Inbox | | Trash | | (etc) | | server2 | | (etc) | | server3 | | (etc) | +-----------+ In another case, I'm trying to use the <html:optgroup> tag, which allows for hierarchical combo boxes I have a folder structure like this: server1 Inbox subinbox Trash Anotherfolder folder3 And when I use this template: <html:select name="identity.fccFolder" onchange="dump('value=' + event.target.value + '\n')" rdf:datasources="rdf:mailnewsfolders rdf:msgaccountmanager" ref="msgaccounts:/"> <html:optgroup/> <template> <rule iscontainer="true" isempty="false"> <html:optgroup uri="..." label="rdf:http://home.netscape.com/NC-rdf#Name"> <html:option value="..." label="rdf:http://home.netscape.com/NC-rdf#Name"/> </html:optgroup> </rule> <rule> <html:optgroup> <html:option value="..." uri="..." label="rdf:http://home.netscape.com/NC-rdf#Name"/> </html:optgroup> </rule> </template> </html:select> (When I tried rooting the server at msgaccount:/, I got results similar to the first example. You'll notice in the above example that I rooted it at one of the servers) This is what I get: +---------+-+ | server1 |V| +---------+-+ | Trash | | Drafts | | Inbox | <html:optgroup> element | Inbox | (first sub-item of optgroup) | AnotherFol| <html:optgroup> element | AnotherF| (first subitem of optgroup) +-----------+ I was expecting this: +---------+-+ | server1 |V| +---------+-+ | Inbox | <html:optgroup> element | Inbox | (first subitem of optgroup) | subinbox| <html:optgroup> element | subinbox| (first subitem of subinbox optgroup) | Trash | | Drafts | +-----------+ I've looked at the DOMs for each of these situations, and the DOM exactly matches the UI, so this isn't a problem with the combo box. What this means: - the template is searching the RDF graph and LOOKING at containment, so it is matching the iscontainer="true" attribute in the rule, however, it is not actually building up content from the children, unless it is queried a few times. Menus are the only thing that seem to be able to requery the datasource though. - it seems to match the isempty="false" rule, as seen in the menus (because File Here only appears on non-empty menus)

I forgot the last part of the last example, add | AnotherFolder| <optgroup> element | AnotherFolder| (first subitem of optgroup) | folder3 | (second subitem of the optgroup)

if someone will point me at the place that content is added to the DOM using a template, I'll look into fixing this myself.

Chris, want some luv, i.e. this bug? (I'm wondering if any of the optimizations that have gone in lately have broken this?)

Okay. - The "move and Copy" menus stuff is a logged bug vs. XPMenus, it is not a problem with templates. See bug 11661. - The "<html:select>" problem is pilot error: your template has no way to specify recursive hookup -- the datasource reveals the servers at the top level; how are we supposed to know that we need to "flatten" the list to include the folders below each server? Try writing the HTML first, and then figure out how to "back" that in to a template. (It may be that you can't in which case, we should file that as a separate bug.) In your second example, uh, yeah, the template is working the way you told it to. I think you need to factor it in to a couple more rules maybe. - The persist-with-trees is a bug with the tree control, not templates. As you note, bug 13252. So let's concentrate on the second issue and say the other two are INVALID or are already logged as separate bugs. I may have screwed up something with HTML. Alecf, if you could point me to a test case, I will happily look at this.

ok, I was theorizing that the odd problems all rooted from templates. I agree then, too - I'll count the other stuff as INVALID.. Anyhow, I'll check in the example above into chrome://messenger/content/am-copies.xul now

alecf: could you re-pull nsRDFGenericBuilder.cpp and try this? There _were_ a number of problems with the 'containment' property.

there were some problems with containment that i fixed, but this is different. we discovered tonight that we're missing a "match" phase after we create the HTML content, so that other rules can recursively apply. will try to fix tomorrow...

Talked with waterson on IRC. I'm going to theorize here, just because I'm curious if I'm getting this: when we actually create the new nodes when we match a template, we're not continuing to descend into the graph. This means we only get toplevel children.... so when we call CreateWidgetItem, we then need to go through that item as a container, and create all it's elements.

I fiddled around in my tree to see if I could get it to do something.. I did manage to get it to create all the children, but it actually added all the children of all the nodes as children to all the siblings of the parents of those child nodes. (That makes sense if you really think about it :)) ..but then the combo box started acting really wierd, I think I put some bogus content nodes in there or something. anyway, waterson sounds like he understands this way better than I do, so I eagerly await the solution to eagerly built content.

fix checked in.

alecf, would you please verify this works? Thanks! -ckritzer

Not to be obnoxious, but this bug is EXTREMELY easy to verify, I don't understand why I have to do it? just go to http://xchat.org/ - if it doesn't crash, then it's fixed. since when does QA not verify bugs that developers have reported?

alecf, i think you appended your flame to the wrong bug.

doh. sorry ckritzer yeah, this works great now...

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.