Looks like there is some timing issues in the content model when we load the data from the datasource. Hewitt saw this problem when we were debugging this in the commercial tree. Let me know if you folks need a test case to work on. Thanks!

Nominating. Commercial tree has seen this behaviour lately!

sure, a testcase whould be nice

What is the end user impact of this bug? What are the prominent consumers of the outliner using a datasource to populate themselves? How rampant is this problem? Does it only occur on slower machines? Thanks.

See bugscape bug 13003 for impact.

varga, The one testcase I had in my mind works fine now. But it doesn't work in one of the commercial module :( Hewitt knows/saw the problem. Prolly he can detail you. Thanks!

To answer samir's questions: 1. (as jelwell mentioned) see bugscape 13003 and 13191 for impact. 2. This problem occurs in our own product. 3. I have seen this problem in my 1 Ghz system.

nsbeta1- per Nav triage team. Both of the cited bugs are fixed, so if there is still some serious problem, please describe it and the impact on users here.

New info is that this also depends on http://bugscape.mcom.com/show_bug.cgi?id=13670, which is nsbeta1+/ADT1. Marking nsbeta1+/ADT1. Jan, do you have time to help on this?

Bugscape 13003 is marked invalid because we choose to ship with something similar but different one. http://bugscape.netscape.com/show_bug.cgi?id=13670 deals with the new one.

Sure, could someone send me a private copy of the bugscape bug ? A testcase demonstrating this problem would be great.

This is a pretty important bug [m5+], shouldn't we try and get it into 1.0?

adding metabug blockage

I don't really understand what is going on here, either. I can only describe the symptoms. In the buddy list, sometimes certain rows will get appended at the wrong level and row index in the view. The buddy list uses the content view, and is generated by an rdf template. reassigning to Jan since he is the tree content view dude

working on a testcase

Taking this on my hitlist.

- fixed AttributeChanged() to only care about its own children

Comment on attachment 79949 [details] [diff] [review] new patch r=bryner

hewitt, can you sr this bug? Thanks.

Comment on attachment 79949 [details] [diff] [review] new patch sr=hewitt

The SR is here, let's tryn and get this one in asap. adt1.0.0.

I'm asking some people to test this out in mailnews but they are saying that the patch fails to build on the branch. Could you provide and updated patch?

It was actually a problem applying the patch, not building with it.

I failed too, in a way I am not comfortable manually fixing (I tried, but seems like there was enough change between the branch and the tree this patch was applied to that I cannot be sure). Could you apply an updated patch for the branch so we can do some testing tonight?

Ok, I did this carefully by hand and feel good about it -- that patch I will be posting should be easily applied to the current branch. There was one chunk of code that appears to have been new to Jan's tree that is not in the branch. That was what was causing the patch to fail. Jan, please look at the patch and verify this is what we need for the branch.

This patch can be used for testing. Ultimately, Jan Varga should validate the patch before it lands.

Comment on attachment 81258 [details] [diff] [review] Patch that works for mozilla1.0.0 branch Yeah, this looks good. Actually, it was patch for optgroups which made this not apply on the 1.0 branch

r=varga

yeah, I had problems with the when I originally tried. I ended up manually doing myseld!

This is fixed in the trunk and the dependent bugscape bug (http://bugscape.netscape.com/show_bug.cgi?id=13670) is verified. Marking this as fixed so that adt can approve this to checkin to the branch.

adding adt1.0.0+. Please check this into the branch as soon as possible and add the fixed1.0.0 keyword after getting drivers approval.

landed on the branch

No driver gave a=. This should not have been checked into the branch. Also, the branch patch has no sr marked. Please justify leaving this patch in to drivers@mozilla.org, and also please obtain an sr= for the branch patch. rjesup@wgate.com for drivers.

I'm confused with this adt=, a= and whatever stuff This patch is almost identical to previous one. I got first sr= after 5 days. This patch was tested by Navigator and Mailnews QA and I was requested to check in to the branch. So now I'm not sure what I was supposed to do actually. In case that this is problem, back it out

I think this was just an honest oversight, made more likely by ADT time pressure (deadline of 3AM!). If there are no known problems with the checkin, could we possibly just get SR= on the changes from the original patch, and a= from drivers? That would be a lot more efficient than backing out, going through the correct Process, and checking in again.

That patch was a part of the binary that was sent around for testing. So, it is very likely good, it was just a matter of manually applying the patch because of some unrelated differences between trunk and branch. My thought is the sr= from the trunk patch is sufficient for the branch one (in fact, the reason I placed that patch here was just to make it easy on the person who had to checkin the patch to the branch, not because it was anything significantly different).

Comment on attachment 81258 [details] [diff] [review] Patch that works for mozilla1.0.0 branch sr=hewitt

Comment on attachment 81258 [details] [diff] [review] Patch that works for mozilla1.0.0 branch retroactive a=rjesup@wgate.com for drivers. Thanks for clearing up what happened.

HUGE thanks to Varga for fixing this bug and also to everyone else involved in this bug!! The dependent bugscape bug is verified in branch and trunk. Marking this as verified.

Just to be sure we are clear of this problem some testing on slow (e.g., 200Mhz) machines should be done in the coming weeks. I ran into some problems today with a newer build and it is not clear to me we are completely out of the woods yet.