9/1 10 m18 Launch mail w/new messages in inbox. 3pane window opens and scrolls new messages. The second from last entry is a blank line. The next prior entry has a duplicate subject with the previous entry. Click on the previous entry and find it's actually another message, this action causes that entry to change it's display and now it looks the same as the next prior entry. Looks like other sync bugs I've seen before.

This is really rather horrible. Nominating for nsbeta3.

nsbeta3+, P3. However, this is probably a tree bug...

I haven't actually seen this, but I'm going to guess this is a tree bug and reassign to hyatt.

removing nsbeta3+ for triage by new owners, qa->jrgm, cc lchiang & selmer How do I reproduce this, considering that when I load 3pane, I don't get the blank line/dup subject, etc?

I can't give steps that guarantee reproducing this. I haven't seen it yet in today's build. One thing to try is setting your prefs to launch mail by default.

I usually launch with -mail switch, isn't that essentially the same?

Seems like it should be, I'm not the one to guarantee that though.

I can't reproduce this specifically, but there are some current tree bugs with some similar behaviours (duplicate and/or missing lines): bug 51227, bug 44093, and bug 43326, which have become a bit more pronounced in this past week.

Never could reproduce, probably fixed by hyatt's related changes last night, resolving as fixed.

I haven't seen this problem on builds I downloaded this week using Steve's scenario and win98. Suresh, since bug 43326 was verified by you and has parts of this scenario can you check this on NT4 and update this bug, then I will verify it or you can.

I think this might have been fixed. I cannot verify today coz scroll bar is bad in today's build. (Just filed a bug on Mail scroll bar: 52847.)

I'm reopening this bug. Here is a simple testcase to duplicate this bug. 1. Launch Mail with new msgs. 2. Click on the Down scroll bar widget once. The thread pane is empty. I can see the contents of thread pane if I resize the window or Scroll up. Tested on today's commercial build on Win NT.

nsbeta3+: typical usage case, manifesting itself as apparent catastrophic data loss.

As hyatt and I were discussing today, this seems to be a result of incorrect scrollbar positioning due to some problem with the reflow we do on tree row size change. adding eric to cc... what do we need to be doing to ensure that the scrollbar gets reflowed when we detect a tree row height change?

I have another theory about this... What if EnsureElementIsVisible is being called before the correct row height is known? Then it would vertically scroll to an inaccurate position. Even if a new reflow came in later that corrected the row height, the tree wouldn't ever scroll the view to the correct position. The thumb would then be "off".

Yes, I'm right. This bug only happens in the modern skin, and in the modern skin, I see a SetRowHeight from 0 to 210, then an EnsureRowIsVisible, which scrolls to 210*aIndex, and then a SetRowHeight increases the height from 210 to 225, so then the position is off... the view needs to be at 225*aIndex, but it's still at 210*aIndex.

What's weird, though, is that I have code in SetRowHeight that is supposed to correct the scrolled view's position. It should be working, but it isn't.

Ok, the scroll correction in SetRowHeight fails because it is trying to scroll past the end of the view. Since we're still in the old row height world, the scroll view's size is much smaller, so you can't actually perform any scrolling correction yet. I have to do this scroll correction in the reflow callback. Will try that and see what happens.

fixed.

hyatt: r=bryner :) sorry I didn't get to it before you checked in, I was in class.

VAF (Verified as Fixed) :) Builds verified: Todays BRANCH builds on all platforms.

I'm unable to verify this on the trunk because I couldn't reproduce it so I don't know what to compare. Could someone (slemer?) who was able to repro this please test it on trunk builds and Verify that it is fixed. If you can then please comment and remove the vrtunk keyword. Thanks.

I'm reopening this bug. I'm seeing this bug in today's commercial Branch builds on Win NT. Exactly the same steps as selmer reported orginally. Adding rtm in the keyword field.

I saw something similar to this in FTP trees yesterday, but never see it in mail. Are you guys in threaded view when this happens? How many messages in your inbox? POP or IMAP? Any other particulars about your config that might be important?

No, I'm NOT in threaded view when I see this bug. I'm using IMAP account, ~170 msgs in Inbox.

Can you reproduce this reliably? Have you tried a new profile? Could you demonstrate it for me?

Trudelle, I couldn't duplicate this bug anymore. I tried with today's branch builds and also with couple of last week branch builds. Last week (thursday or friday) I deleted the profile in which I saw this bug. So I tested this today with a new profile. Maybe it has something to do with that particular profile.

I'm not seeing this with today's build. I saw one minor paint problem where a cropped item stayed cropped even after it was scrolled completely into view. Attempting to reproduce that failed, so I'm not sure what was special about that one time.

resolving as wfm

VERIFIED. We've got plenty of other, more specific bugs filed for this.