This was the underlying cause of 12289, but we can work around this so this doesn't need to be done pre-beta. Basically when a tree is rerooted, the selection should be cleared. Otherwise, when you start selecting in the tree, the selection count is messed up and it starts acting like it's in multiselection mode.

My hands have deteriorated to the point where I can no longer type. I need help. If you think you can fix this bug on your own, please take it away from me. If you'd like to volunteer to be my hands for a specific bug, then I'll be happy to come up to your cube and sit with you and fix the bug (assuming you have the patience for that).

I will be your hands here.

I'll take this.

I may have this bug all wrong. What's actually happening is that the tree is maintaing the selection when rerooted. The elements that the selection holds onto have their mDocuments reset to null. This means that when the next item is selected, in the newly rerooted tree, when it tries to clear the selection, it can't because when mDocument is null it can't remove the selection. This guarantees the new selection will have more than 1 item and hence the multiple selection problems that occur. It seems to me we have two choices here. One is that when the tree is rerooted, the tree needs to remember the id's of the current selection and then after rerooting it needs to search the new content nodes that were created for the saved id's and add them to the selection. Or, the client that forces the tree to reroot itself needs to do something similar. If we go with the first choice then the tree shouldn't clear selection when rerooted and anyone who wants this (for example the folder pane when selecting a new folder) needs to use the tree api's to clear the selection like we are currently doing. With the other choice clients will be required to save off the selection themselves (examples of this are sorting and changing views in mail).

a piece of this problem is that the tree doesn't KNOW it's been rerooted, it only knows that much of it's content is going away. Really, the root tree element needs to watch it's children so that when a child node goes away, it removes it from the selection list.

yes, sometimes I just wish that we didn't have to destroy the old tree if we knew we were going to reuse all of the same items. But I bet that would be hard and I'm sure there are cases where you don't want that. Wait, I see your point. It seems like we need to notify the tree that this has happened, if we want to go this route.

it does this over in nsXULelement.cpp (or in the doc, don't remember which).

Doh, I fixed this last week (thanks to putterman, actually)

I don't know how to 'reroot' a tree. Could someone please provide a testcase that will allow me to see the bug in old code and see the fix in a current build? Otherwise, if the owner/reporter could verify this bug that'd be cool too.

putterman to verify if he wishes