50224 - Crash after initiating search again, changing subfolder option.

Status: VERIFIED WORKSFORME

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

Description

[laurel]

Using aug24 commercial build

I'm able to consistently crash when doing a search on a subfolder (which also
has subfolder) which produces a match while the "search subfolders" option is
disabled, then I reinitiate the same search with the "search subfolders" option
enabled.

1.  From mail window login to mail account.(IMAP, haven't tried POP yet, but
IMAP reproduced crash on all platforms over different profiles.)
2.  Select INBOX, then Search|Search Mail/News Messages.  In search dialog,
select a folder in search scope dropdown on that same mail account which is a
subfolder that also has a subfolder.
3.  Leave the "search subfolders" checkbox disabled (it is disabled on dialog
launch by default).
4.  Initiate a search which will produce a match.
5.  Enable the "search subfolders" checkbox and click Search to reinitiate the
same search in step 4, but this should search the subfolder and its
child/subfolder.  A crash occurs.

Talkback incidents submitted, will attach as soon as I can access them.

Comment 1

[laurel]

Attachment: talkback 16259780 mac OS

Comment 2

[laurel]

Attachment: talkback 16259604 NT 4.0

Comment 3

[David :Bienvenu]

I think Alec might have a clue about this - I don't. It's nothing to do with
IMAP, and doesn't seem like it has to do with the search backend either.

Comment 4

[laurel]

Since you just did the fix for searching subfolders (and put the button back in)
I thought this might be assignable to you, bienvenu. I'm wrong again.

Comment 5

[Alec Flett]

ugh.. this is a mess. It's XUL stuff, but it could be because of strangeness in 
my datasource... it happens when we re-root the tree

Comment 6

[laurel]

You know I'm seeing frequent crashes when changing parameters other than search
subfolder and reinitiating a search... trying to contact talkback now to see if
the reports look the same as this one's.

Comment 7

[lchiang]

+, p1 per mail triage

Comment 8

[Alec Flett]

I'm not seeing this crash on my first few attempts.. (NT, with IMAP)

Comment 9

[lchiang]

PDT: this is a P1 due to crash

Comment 10

[leger]

Need consistent reproducibility.  Moving to P3.  Adding [PDTP3]

Comment 11

[laurel]

Using aug30 commercial build, I've reproduced on linux and mac.

Comment 12

[lchiang]

alec - do you see this? I'm wondering if we need to move back to P1 if 
reproducible.

Comment 13

[scottputterman]

I'm not seeing this either.  What I am seeing is that Search subfolders isn't 
working for me at all.

Comment 14

[scottputterman]

I take back what I said.  I was trying to search a subfolder that was more than 
one level deep.  It looks like we don't search subfolders past the first level.

Comment 15

[scottputterman]

OK, I was able to reproduce this.  The stack is very similar to 48968. Both have 
to do with adding something and then rerooting.

Comment 16

[leger]

Putting on [dogfood+] radar.  Blocking search testing.

Comment 17

[lchiang]

second pass: - per mail triage unfortunately.  User would have to initiate 
search again on a subfolder to see the crash.  Bug 48968 is still a + so 
hopefully fixing that bug will fix this bug if the root of the bug is at a tree 
level.

Comment 18

[David :Bienvenu]

I disagree with minusing this - I don't think this has anything to do with 
changing the sub-folder option, so your rationale for cutting it is shaky. I 
think there's something fairly seriously wrong in the content model stuff that 
we should at least understand before cutting.  Alec, what do you think?

Comment 19

[selmer (gone)]

After Alec responds, we need to know what solution is being proposed so we can
evaluate this properly.  Adding [b3 need info] so we keep this on our radar.

Comment 20

[Alec Flett]

I think in reality this is just a dupe of the other bug.

Comment 21

[scottputterman]

I'm guessing this might be an RDF bug since it's showing up in two different 
pieces of our code. cc'ing waterson in case he has any ideas.

Comment 22

[David :Bienvenu]

Yes, I agree it's a dup. The PDT should be aware that this bug could crop up in
all sorts of places - the two we know about are search and address book, but I
bet other areas in the code are vulnerable and we should really understand the
bug before latering it. 

Comment 23

[Alec Flett]

address book! Hey, maybe this isn't my bug. I would be so happy :)

Comment 24

[chuang]

The talkback report did look similar to bug 48968.  As for now,  I can't 
reproduce bug 48968 in address book where I could reproduce last week or two.  
Nothing has changed in address book code for fixing 48968 though.

Comment 25

[selmer (gone)]

Since 48968 just got marked WFM, is this bug also gone?

Comment 26

[laurel]

Using sep6 commercial build:
Haven't been able to reproduce over several tries on NT, linux or mac.
Calling worksforme.

Comment 27

[laurel]

.