66583 - tree appears empty after calling endBatch() even though it isn't.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[(not reading, please use [e-mail] instead)]

to reproduce, see if #66576 is fixed, if not apply the patch from that bug.

load a folder with 100 messages.  select the first 96, hit delete.

you should be left with 4 messages.  instead, after calling endBatch(), the
thread pane is empty.  if I switch folders and come back, the 4 messages show up.

until I do some debugging, I'll keep this bug.  it might not turn out to be a
tree batching bug.

Comment 1

[(not reading, please use [e-mail] instead)]

accepting

Comment 2

[(not reading, please use [e-mail] instead)]

ok, I'm pretty sure its one for hyatt.

I'm consistently able to reproduce this, and if I click on the columns, the
missing messages will come back.

as hyatt knows, there is code in the XULSortService to remove the treechildren
element from the tree, and then add it back (we also re-set the document of the
treechildren element.)

a possible hack fix would be to do that in nsXULTreeOuterGroupFrame::EndBatch()

comments?

Comment 3

[(not reading, please use [e-mail] instead)]

Attachment: a fix, but a nasty one.

Comment 4

[(not reading, please use [e-mail] instead)]

hyatt, please take a look at the attached patch.  basically, I stole the code
from

I'm sure isn't not the best fix, but it does fix this bug.

can you take a look and let me know if you have suggestions?

In my local tree, I've also cleaned up XULSortServiceImpl::DoSort() to call
BeginBatch() and EndBatch(), so the hack is only one place.

Comment 5

[(not reading, please use [e-mail] instead)]

actually, my patch some serious problems. selection and scroll position get
messed up after a multiple delete.

Comment 6

[David Hyatt]

Yes, that's why you can't remove the child like that.  Let's just get this
targeted at 0.8, and I'll take a look at it.

Comment 7

[(not reading, please use [e-mail] instead)]

hyatt, thanks for taking this bug.  mozilla 0.8 would be great.

adding ben, he'll be using the tree batching API for bookmarks.

Comment 8

[Peter Trudelle]

->moz0.9

Comment 9

[Dan Rosen]

i always subconsciously attributed this to a missing repaint, but i guess it's
not that simple... cc'ing me.

Comment 10

[Peter Trudelle]

->future, should be obviated by new tree work for mail.

Comment 11

[David Hyatt]

Batching APIs are now irrelevant.  Use outliner. :)

Comment 12

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

Is this bug truly obsolete Seth? (asking only because it mentions bug 66576,
which is still also open).

Comment 13

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

This bug says tree, and I'll let bug 66576 stand for any batching that will be
addressed in the outliner widget code.  Seth, Hyatt, if I'm wrong, smack me
(rather, re-open this bug)