Can't "re-root" a xul:treeitem or xul:treebody by changing the value of the 'id' attribute.

Marked as M3, blocking Scott & mailnews from changing the folder pane. I am working on this should have it done this afternoon.

Okay, I've implemented code in the generic builder that notices when the "id=" attribute changes on a piece of content and rebuilds the content model from that point down. Hyatt: I'm reassigning this bug to you, because for all pieces of content except the WidgetContentInsertionRoot, this is buggy. Specifically, because of the "table hackery", the destruction of a parent node does not clean up the children properly (this happens to work in XUL because I did a recursive descent to destroy kids on the content side). We need to fix the tree code so that it destroys child frames properly. Anyway, Scott: you should be unblocked for dogfood because you just need to set the "id=" attribute on the treebody anyway (which all works just fine and dandy). Remember, use "treebody.setAttribute('id', newId)", _not_ "treebody.id = newId", because we don't have JS reflection of attributes working yet.

Removed the M3 milestone, because the part that Scott needs is fixed now.

setting p2 for m3

Scott are you still blocked by this? if no one is blocked lets move to M4.

I'm not sure yet. As of Friday I wasn't able to get this to work(the error could be my code), but I'll pull a new tree and try it out.

This is identical to another bug already filed against me. I'll mark the other bug as a duplicate of this one.

*** Bug 3426 has been marked as a duplicate of this bug. ***

Actually, this may be two separate bugs, but what the heck. I think that I have a fix for the part where changing the ID of an element screws up the content model (but not the part for destroying frames). But, I'm not sure where the mail code lives that I'd use to test this theory. I have a little test in my own tree that I've fixed...

Chris, you can send me or scott Putterman a patch if you want us to try it out for you. I'm about to send you email instructions with regards to running the mail app. I'll be posting instructions to mailnews mozilla newsgroup later today as well.

My fix isn't required for M3.

Pushing off to M5

Fixed. Waterson, you should let me know if the recursive descent hack over in the builders is still there. I couldn't find it. YOu should only have to remove the parent content node now... you don't have to descend into the children and remove them now.

Chris, can you help us verify this bug? If you agree the resolution is correct, please mark it as Verified. Thanks!