121164 - Unignored threads never properly returned to All or Unread Threads view

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Jim Henderson]

In Netscape 4.x, ignored threads were tagged with an icon so you could tell they
were ignored - and more importantly, you could ignore them a second time to
toggle the flag.  This no longer seems to be the case in Mozilla builds
2002011921 and later (I haven't tried earlier builds to see if it's something
that vanished) on Win32 and Linux platforms.

Comment 1

[laurel]

Yes, you can unignore a thread.  Use the ignore command/shortcut on it again and
it will be in the regular state again.  Worksforme using jan22 commercial trunk
build
We currently have a bug about no icon - see bug 72279.

Marking this one worksforme.

Comment 2

[laurel]

verified worksforme

Comment 3

[Jim Henderson]

I'll try it again, but I repeatedly attempted this a couple nights ago and
confirmed that a thread ignored could only ever be viewed again by selecting the
option to view ignored threads.  If I can still reproduce, I'll update the bug;
it might be a few days before I can update it, though.

Comment 4

[laurel]

OK, I see there is indeed a bug in the View where the thread never (even after
exit) gets included in All messages view (or Threads with unread even when new
replies come in and are listed as unread) when Ignored Threads is off.  For
development's info: I see this was also present in 4.x

In any case, you can indeed unignore the thread and it will show new replies as
New.  Caveat is that you'll need to either switch to the Unread messages view or
use All view with Ignored Threads ON.

I'll reopen this and change the summary to reflect the real issue, that the
unignored thread is never again included in all messages view (or unread threads
view) if ignored threads toggle is off.

Comment 5

[Boris 'pi' Piwinger]

I found this bug when I wanted to report this observation with Mozilla/5.0 (X11;
U; Linux i686; en-US; rv:1.2b) Gecko/2002100214:

I had a thread, pressed k to ignore it. Worked as intended.

Then I wanted to unignore it and pressed k on it again. The ignore icon went
away.  I left the grop and the thread was not only hidden (so I had to allow to
show ignored threads), also the ignore symbol was back.

If I don't missread this bug, this even worsens the problem.

Since an average user will never be able to find a thread which was once
ignored, I marked this as major. Furthermore, I replace mozilla0.9.9 with the
next release.

pi

Comment 6

[Boris 'pi' Piwinger]

This bug means that once ignored threads (might have happened in error) are in
effect lost for ever. This is not strictly dataloss, but very close. Requesting
blocking for 1.3b.

pi

Comment 7

[David :Bienvenu]

this works fine for me on today's trunk build. I wonder what I'm missing.

Comment 8

[Boris 'pi' Piwinger]

I still have this problem in 1.3b release. Mark (this easily happens by mistake)
a thred as ignore. Change to another group. Realize you did something wrong. Go
back. Check View/Messages/Ignored Threads. Unignore (the red symbol disappears).
You can even watch the thread now. Uncheck View/Messages/Ignored Threads. Change
group. Go back. Don't find the thread -> in effect dataloss.

pi

Comment 9

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 10

[Boris 'pi' Piwinger]

dataloss by definition is critical.

What can we do to track this down? AFAICS the information on the ignore/watch
status is saved to the news.group.name.msf file.

Now I played around with a thread. As described in comment 8 I could also watch
a previously ignored thread. But when you come back it is again ignored.
Unignored now reveals it is still watched. This seems to imply, that a thread
can have both the watched and the ignored status at the same time. This, of
course, does not make any sense.

So what fails is the deletion of the ignored status from the .msf file.
Alternatively only one of those would be allowed, so it would be overwritten.

pi

Comment 11

[David :Bienvenu]

taking - I've not been able to reproduce this but I'll try some more.

Comment 12

[David :Bienvenu]

Attachment: proposed fix

I believe what's going on here is that the msg hdr and the thread object were
getting out of sync w.r.t. the ignored flag. This flag really should only be
set in the thread object - that's where we tend to manipulate it, so we don't
ever clear it in the msg hdr.

Comment 13

[David :Bienvenu]

Comment on attachment 129883 [details] [diff] [review]
proposed fix

this patch also has a little performance optimization when trying to find the
first new message when there is no new msg.

Comment 14

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

Comment on attachment 129883 [details] [diff] [review]
proposed fix

which did we null check pResultIndex before?  is it never null?

r/a=sspitzer for 1.5 beta, assuming it is safe to remove that null check.

Comment 15

[David :Bienvenu]

yes, I checked that no one ever passes in null.

Comment 16

[David :Bienvenu]

fix checked in.

Comment 17

[Boris 'pi' Piwinger]

Verifying:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030818

pi

Comment 18

[David :Bienvenu]

*** Bug 122650 has been marked as a duplicate of this bug. ***