Steps to reproduce: Install ChatZilla or create a fresh profile connect to moznet/#chatzilla Move the userlist to the right (uncheck the box which puts it on the left.) The userlist is now empty. The box is there, (I can hide and show it with ctrl+shift+l) and /names displays the users in the channel just fine, however nothing is actually displayed in the userlist. It remains empty even if you move it to the left. Reproducible on ChatZilla 0.9.77-rdmsoft [XULRunner 1.9a2pre/2007012208] and Chatzilla 0.9.77 [Firefox 3.0a2pre/2007012204] (Possibly related) whenever I open a new chatzilla tab, I get the following error in the JS Console: Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.sessionHistory]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/bindings/browser.xml :: :: line 572" data: no] Source File: chrome://global/content/bindings/browser.xml Line: 578

The JS Console error in unrelated, that's happened for ages and is nothing to do with us (it's a bug elsewhere). Mind you, I think the tree thing is a bug elsewhere too, like in the Template Builder...

Is this problem still happening on trunk? It sounds like a serious bug on trunk that would need to be fixed separately... Also, is there a (decent) regression window at all?

Confirmed on SeaMonkey 2007061302. I'll see about regression testing this sucker...

Finally got it narrowed down. This bug started in trunk, somewhere between SeaMonkey-2006-03-08-10-trunk and SeaMonkey-2006-03-09-10-trunk. This is NOT a ChatZilla bug, as both revisions of SeaMonkey were running the same rev. of cZ (0.9.78.1). Something changed here, perhaps: http://bonsai.mozilla.org/cvsquery.cgi?sortby=Date&date=explicit&mindate=2006-03-08&maxdate=2006-03-10&cvsroot=%2Fcvsroot

See also: #330167 Same bug, it seems, but it's NOT resolved. as SeaMonkey-2006-03-15-11-trunk (2 days after #330167 was marked RESOLVED) is still broken.

If this is a Core bug, please move to Core as needed.

This bug does not exist in XULRunner or Firefox. It must be a Seamonkey related glitch.

-'ing this due to comment #7.

(In reply to comment #8) > -'ing this due to comment #7. > As far as I know that comment is wrong. I've seen this happen in Firefox and XULRunner as well. In fact, the Reporter specifically mentioned it being reproducible on XULRunner and Firefox. I just tried, and reproduced it on XULRunner trunk that's not even 2 weeks old. Re-requesting. As far as I can tell, moving RDF <tree>s across the document is simply broken on trunk - it loses its .view property (tested this). Moving to trunk in a bit.

Uh, obviously I meant moving to Core. CC-ing bz to get this on radar (and also because he requested the move)

Renominating, as this seems to be an across-the-board regression in XUL template handling, and because the minus was based on incorrect data... Neil, can you take a look at this?

Summary was clearly innaccurate after move, fixing.

This is a somewhat reduced version of the CZ userlist thingy. I couldn't figure out how to reduce it much further without breaking the RDF stuff. It needs UniversalXPConnect to run because rdf trees don't work without that privilege.

Also note that oddly, the testcase on bug 330167 does work on trunk for me, whereas this testcase does not.

Plusing due to the new data - setting to P3 - if you think that's wrong please adjust

This is because the database and builder are cleared when a node is removed from the document. You would need to readd the datasource using AddDataSource when the node is inserted.

OK, but you never needed to do that before... Is this something that is not supposed to be fixed, or...?

Probably won't be fixed. The database is stored in the builder and the builder doesn't apply nor make sense to apply to nodes not in documents. There may be value in storing the database somewhere else though.

We just dropped the RDF view, so we (ie ChatZilla) officially don't really mind anymore. :-) So per comment #18, is this WONTFIX or not? Is there a bug about storing the DB somewhere else?

It should be fixed in some way, but not until after 1.9