361374 - Ignore Thread is dangerous, unread messages in ignored threads should not be counted in newsgroup's message count

Status: RESOLVED DUPLICATE of bug 311774

(Thunderbird :: Mail Window Front End, defect)

Description

[Adam M.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Occasionally when I reply to a thread in a newsgroup, the whole thread will vanish from the list of messages. Future replies to the same thread never show up.

In addition (and quite possibly because of this), the unread message count gets out of sync. The entry in the folder view may show 10 or 20 unread messages but there are no unread messages visible in the thread list. Switching to the "unread message" view shows nothing. I suspect these are the replies to threads that have been disappeared.

I use a classic view that's sorted by date, descending, threaded, with no grouping.

I've confirmed in another news reader that the thread wasn't simply canceled.

This bug existed in previous versions as well.

This has happened to about 15 threads so far.

Reproducible: Sometimes

Steps to Reproduce:
These repro steps are rather poor.

1. Set up a news account and subscribe to a newsgroup. (I'm using microsoft.public.windows.powershell on news.microsoft.com)

2. Reply to a thread.
Actual Results:  
Thread vanishes from the UI. (I'm not sure if it's immediate or when my reply is picked up on the next hit to the server.)

Expected Results:  
The thread should stick around so I can follow it.

Arguably a data loss bug, although the thread /might/ still be in the folder's data file. Next time I notice a thread disappearing I'll try to remember the title and grep the data file.

Comment 1

[Magnus Melin [:mkmelin]]

Which version of thunderbird are you using? Can you attach the headers of a message in a thread that disappeared?

Comment 2

[Adam M.]

I'm using 1.5.0.7

I don't think such a bug has been fixed in the 1.5.0.8 build, but I can upgrade if you like.

Kind of tough to attach the headers when I can't access the thread, but like I said, next time it happens I'll try hard to remember the title and grep the data file to see if I can find one.

A question for you: Is there an easy way to grep for something that marks an entry as unread? Because what usually happens is that phantom unread messages build up... and it may be possible to look in the data file and find the message IDs of the unread messages, and then look for those message IDs.

Comment 3

[Adam M.]

It just happened again, I think. But I don't remember the title because it was a thread I didn't care about.

What I did prior to that, though, was mark another news message (written by me) read by letting the cursor sit on it for some seconds. Then I marked the one I didn't care about read by selecting it and hitting V...

Wait, I've just figured this out. I stumbled upon that key accidentally but never knew what it did -- it wasn't in the menus -- but it seemed to mark a thread as "read". V is actually K on my wacky keyboard, I now realize, and searching the menus reveals that K is "Ignore thread".

But the effects of "Ignore thread" aren't visible immediately.. it looks just like marking the thread as read. The thread doesn't disappear until later, when you leave the pane and come back.

I imagine you guys don't hide the thread immediately because you want to give the user a chance to correct the mistake of accidentally ignoring a thread. (?) But the thread is not obviously ignored so it seems to just disappear suddenly "when I'm not looking".

Playing with the columns, I notice that you can add the "Thread" column, which will indicate the ignored status.

It's not even obvious that you can un-ignore a thread, though, because an ignored thread has no command to un-ignore it (except the Watch Thread) command. I discovered that "Ignore Thread" is a toggle, but it's not indicated that way on the menu.

I guess I propose the following:

First, since the Ignore/Watch Thread commands are toggles, their menu items should be checked if the thread is currently watched/ignored.

Second, since if the Thread column is not in the view, there's currently no easy way to see if a thread in the current view is being ignored (and will suddenly disappear later). So perhaps it should be rendered differently, eg, in a color that gives less contrast (eg, gray on white instead of black on white).

Third, when somebody ignores a thread, especially using a keyboard shortcut which could be easily hit accidentally (as I did originally), you may want to warn the user as to what will happen, and, how to undo the action. Of course, the user can choose not to show the message again...

Fourth, consider whether counting unread messages of ignored threads (when the view does not include ignored messages) is really desirable. If somebody ignores a thread, they probably don't want to see the item in the folder view sitting there bold (meaning "hey there's an unread message, come look at me!") when the unread message is a reply to a thread they don't care about.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> I imagine you guys don't hide the thread immediately because you want to give
> the user a chance to correct the mistake of accidentally ignoring a thread. 

I believe that's correct.  Also: you can use  View | Threads | Ignored Threads  to show the ignored threads in the thread pane.


> Playing with the columns, I notice that you can add the "Thread" column, which
> will indicate the ignored status.

The 'Thread' column is turned on by default; you must have turned it off earlier.


> First, since the Ignore/Watch Thread commands are toggles, their menu items
> should be checked if the thread is currently watched/ignored.

There may already be a bug to this effect.  It's not a bad idea, but unless somebody with a mission to make TB a better newsreader comes in and starts adding features like this, it won't happen -- and there are far more pressing issues with TB's newsreading functions.


> Second, since if the Thread column is not in the view, there's currently no
> easy way to see if a thread in the current view is being ignored (and will
> suddenly disappear later). So perhaps it should be rendered differently, eg,
> in a color that gives less contrast (eg, gray on white instead of black on
> white).

You can customize this yourself.  Place the following in your userChrome.css (in the chrome subdirectory of your profile):
=========
treechildren::-moz-tree-cell-text(news, ignore) /* ignored threads top msg */
{
  color: #AAA !important;
} 
=========
This only colors the topmost entry in the thread, but that should suffice.


> Third, when somebody ignores a thread, especially using a keyboard shortcut
> which could be easily hit accidentally (as I did originally), you may want to
> warn the user as to what will happen, and, how to undo the action. Of course,
> the user can choose not to show the message again...

That will not be done.  Nobody who actually uses news wants this, and eventually the newbie will figure it out.


> Fourth, consider whether counting unread messages of ignored threads (when the
> view does not include ignored messages) is really desirable. If somebody
> ignores a thread, they probably don't want to see the item in the folder view
> sitting there bold (meaning "hey there's an unread message, come look at me!")
> when the unread message is a reply to a thread they don't care about.

That cannot be done.  When the newsserver is first queried, the only value returned is the number of messages on the server since the last fetch.  The 'ignore' aspect is entirely client-side and can't be determined until the headers for each message are downloaded.


The conceit of calling this "dangerous" is too precious for words.  This is a news-reader function we're talking about.  Losing track of a thread is not dataloss.

Comment 5

[Adam M.]

(In reply to comment #4)

Thank you for your reply.

> You can customize this yourself.  Place the following in your userChrome.css
> (in the chrome subdirectory of your profile)...
Awesome, thanks.

> > Third, when somebody ignores a thread, especially using a keyboard shortcut
> > which could be easily hit accidentally (as I did originally), you may want to
> > warn the user as to what will happen, and, how to undo the action. Of course,
> > the user can choose not to show the message again...
> 
> That will not be done.  Nobody who actually uses news wants this, and
> eventually the newbie will figure it out.
I don't think the blanket statement "nobody who actually uses news wants this" is true. I use news almost daily and have been using it for almost a decade. The simple fact is that unless somebody has experience with the in-built Ignore Thread functionality (this is not a feature I use), they may occasionally press a key by accident, have threads disappear at some later point, and not know what happened. (So perhaps a more accurate blanket statement is "nobody who routinely ignores news threads wants this".)

Users may eventually figure it out, as I did, but in the mean time it may cause a fair amount of frustration. And you should also consider that everybody is a newbie at some point, and it's a generally good idea to lower the bar, and in particular not allow them to hurt/frustrate themselves too badly, which may cause them to give up on something entirely.

> > Fourth, consider whether counting unread messages of ignored threads (when the
> > view does not include ignored messages) is really desirable. If somebody
> > ignores a thread, they probably don't want to see the item in the folder view
> > sitting there bold (meaning "hey there's an unread message, come look at me!")
> > when the unread message is a reply to a thread they don't care about.
> 
> That cannot be done.  When the newsserver is first queried, the only value
> returned is the number of messages on the server since the last fetch.  The
> 'ignore' aspect is entirely client-side and can't be determined until the
> headers for each message are downloaded.
Then it can be done when the headers are downloaded. The default behavior even is to automatically download the headers when the folder is opened.

> The conceit of calling this "dangerous" is too precious for words.  This is a
> news-reader function we're talking about.  Losing track of a thread is not
> dataloss.
It is data loss if you consider a more practical (user-centric) definition of the word. If somebody is no longer able to view some data (note that the inability may not be a hard physical limit), then the data is, in effect and as far as the user is concerned, lost. A file accidentally deleted may still be recovered, but unless one knows this and has the tools to do so, the data is lost. Even a file misplaced is lost, as keys are stereotypically. It's really not very comforting for the person late for an appointment to know that "the car keys still exist in the world, somewhere".

You can say that the solution is that people simply need to develop better memories, but I think making the keys unlosable in the first place is better all-around.

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to comment #5)
> > > Fourth, consider whether counting unread messages of ignored threads (when the
> > > view does not include ignored messages) is really desirable. If somebody
> > > ignores a thread, they probably don't want to see the item in the folder view
> > > sitting there bold (meaning "hey there's an unread message, come look at me!")
> > > when the unread message is a reply to a thread they don't care about.
> > 
> > That cannot be done.  When the newsserver is first queried, the only value
> > returned is the number of messages on the server since the last fetch.  The
> > 'ignore' aspect is entirely client-side and can't be determined until the
> > headers for each message are downloaded.
> Then it can be done when the headers are downloaded. The default behavior even
> is to automatically download the headers when the folder is opened.

clarified summary

Comment 7

[Joshua Cranmer [:jcranmer]]

DUPL of bug 311774, see esp. comment #5 of said bug.