51084 - 3pane: tree gets all horked up

Status: VERIFIED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

[selmer (gone)]

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.

Comment 1

[selmer (gone)]

This is really rather horrible.  Nominating for nsbeta3.

Comment 2

[selmer (gone)]

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

Comment 3

[scottputterman]

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

Comment 4

[Peter Trudelle]

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?

Comment 5

[selmer (gone)]

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.

Comment 6

[Peter Trudelle]

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

Comment 7

[selmer (gone)]

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

Comment 8

[John Morrison]

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.

Comment 9

[Peter Trudelle]

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

Comment 10

[esther]

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.

Comment 11

[Suresh]

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.) 

Comment 12

[Suresh]

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.

Comment 13

[Peter Trudelle]

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

Comment 14

[Brian Ryner (not reading)]

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?

Comment 15

[David Hyatt]

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".

Comment 16

[David Hyatt]

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.

Comment 17

[David Hyatt]

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.

Comment 18

[David Hyatt]

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.

Comment 19

[David Hyatt]

Attachment: Proposed fix.

Comment 20

[David Hyatt]

fixed.

Comment 21

[Brian Ryner (not reading)]

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

Comment 22

[Suresh]

VAF (Verified as Fixed) :)

Builds verified: Todays BRANCH builds on all platforms.

Comment 23

[Asa Dotzler [:asa]]

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.

Comment 24

[Suresh]

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. 

Comment 25

[Peter Trudelle]

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?  

Comment 26

[Suresh]

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

Comment 27

[Peter Trudelle]

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

Comment 28

[Suresh]

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. 

Comment 29

[selmer (gone)]

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.

Comment 30

[Peter Trudelle]

resolving as wfm

Comment 31

[[e-mail] (gone - use [e-mail] instead)]

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