267594 - Thunderbird doesn't display watched / ignored thread icons

Status: VERIFIED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Chris Ilias [:cilias]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041103 Thunderbird/0.9 Mnenhy/0.6.0.104

Thunderbird doesn't display watched thread icons.
Tested on 0.9.
Veariety of servers, variety of methods marking threads. Even threads previously
marked as watch do not show the icon.
View -> Threads -> Watched threads with unread works.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Doug]

Confirm here on TB 0.9 and Win2K.

Comment 2

[Brion Vibber]

Confirmed with 0.9 and 2004-11-04 nightly on Mac OS X 10.3.
This is a usability killer for me; I'm downgrading back to 0.8 for now.

Comment 3

[Daniel Buchholz]

Confirmed on 0.9/XP and I have no icon display for either ignored or watched threads

Comment 4

[Chris Ilias [:cilias]]

This, as far as I can tell, is not a theme bug.

I've tried the themes Noia-Cute Ver 1.4.4 1.4.4, and Nitpick 0.1.8.2. Still no
icons.
<http://update.mozilla.org/themes/showlist.php?application=thunderbird&category=All>

I didn't see them after extracting the appropriate GIFs from qute.jar and
placing them in my profile's chrome folder, then adding the following script to
my userChrome.css:

/* ..... new thread icons for watch and ignore ..... */

treechildren::-moz-tree-image(news, threadCol, watch) {
  list-style-image: url("thread-closed-eye.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, ignore) {
  list-style-image: url("thread-closed-kill.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, watch, offline) {
  list-style-image: url("thread-closed-offl-eye.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, ignore, offline) {
  list-style-image: url("thread-closed-offl-kill.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, hasUnread, watch) {
  list-style-image: url("thread-new-closed-eye.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, hasUnread, ignore) {
  list-style-image: url("thread-new-closed-kill.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, hasUnread, watch,
offline) {
  list-style-image: url("thread-new-closed-offl-eye.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, hasUnread, ignore,
offline) {
  list-style-image: url("thread-new-closed-offl-kill.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, hasUnread, watch, open) {
  list-style-image: url("thread-new-open-eye.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, hasUnread, ignore, open) {
  list-style-image: url("thread-new-open-kill.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, hasUnread, watch,
open, offline) {
  list-style-image: url("thread-new-open-offl-eye.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, hasUnread, ignore,
open, offline) {
  list-style-image: url("thread-new-open-offl-kill.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, watch, open) {
  list-style-image: url("thread-open-eye.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, ignore, open) {
  list-style-image: url("thread-open-kill.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, watch, open, offline) {
  list-style-image: url("thread-open-offl-eye.gif") !important;
}

treechildren::-moz-tree-image(news, threadCol, container, ignore, open, offline) {
  list-style-image: url("thread-open-offl-kill.gif") !important;
}

I'm not a coder or a theme author, but I hope that helps.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mmh I can only test it with version 0.9 (20041103) but I can see the same
behavior. The icons aren't displayed and no newly set watched thread is
displayed when choosing "View -> Threads -> Watched threads with unread".

Chris try to set a watch for a new thread. Change the View to the one above. Can
you see the newly added watched thread? If you can't see this thread, we have
not only the icon problem. IMO you aren't able to set this flag. Because of that
no icon is displayed.

This should block aviary1.0. 

Comment 6

[Chris Ilias [:cilias]]

(In reply to comment #5)
> Mmh I can only test it with version 0.9 (20041103) but I can see the same
> behavior. The icons aren't displayed and no newly set watched thread is
> displayed when choosing "View -> Threads -> Watched threads with unread".

If I mark a thread as watched, that was not previously a watched thread, then go
to "View -> Threads -> Watched threads with unread", the thread *does display*.
Just no icon. Of course, I have to make sure that it has an unread message in
it, and that it wasn't already marked as a watched thread. Kinda hard to tell
without an icon. :-)

Comment 7

[Scott MacGregor]

what's a watched thread icon? screen shots appreciated.

Comment 8

[Brion Vibber]

Attachment: Screen shot of same threads in 0.8 and 0.9, showing missing 'watched thread' icon

Display is in 'Threads -> All' mode. The first line shows some random thread,
the second shows a watched thread (also there is a 'replied' icon), and the
third line shows an unread message with nothing else in the thread. In 0.8, the
watched thread shows a special icon instead of the generic thread icon. In 0.9,
the watched thread doesn't show that watched thread icon, instead appearing
like any other thread -- there is no visual way to identify the thread as
watched.

(The exact icons may differ in Windows and Linux; this is the default theme on
Mac OS X.)

Comment 9

[Scott MacGregor]

looks like the watched property is never getting appended to the cell properties
for a watched thread anymore. Probably a regression from our grouped view work.
Or maybe we inadvertantly picked up part of the trunk's change for Bug #112833
while porting some grouped view stuff to the branch....I need to investigate
some more. 

Comment 10

[Chris Ilias [:cilias]]

I've done some back tracking through the win32 aviary nightlies.
2004-11-02-14-0.9 is the first build with this regression.
2004-11-01-14-0.9 is fine.
I'll post a win32 screenshot.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Scott, could that happen because of your checkin for
mozilla/mailnews/base/src/nsMsgGroupView.cpp?

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/mailnews/base/src&command=DIFF_FRAMESET&root=/cvsroot&file=nsMsgGroupView.cpp&rev1=1.2.2.14&rev2=1.2.2.15

Comment 12

[Scott MacGregor]

David, this checkin falls in the range in which this problem showed up:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/mailnews/base/src&command=DIFF_FRAMESET&file=nsMsgDBView.cpp&rev1=1.170.6.19&rev2=1.170.6.20&root=/cvsroot

is it possible that flags from the msg hdr fail to indicate the watched state
but that state is reflected in m_flags[aRow]? 

Comment 13

[David :Bienvenu]

yes, definitely...

Comment 14

[David :Bienvenu]

and by yes, definitely, I mean, definitely not. This works fine on trunk builds,
and it's GetCellProperties that determines the watched icon, and that's using
the m_flags array still. Something else is going on...

Comment 15

[David :Bienvenu]

Attachment: proposed fix

not sure how these lines got lost...I probably screwed up applying a patch or
something...

Comment 16

[David :Bienvenu]

Attachment: better fix

it was the flags change for the new flag, but on the trunk we were getting the
thread flags from the thread object, which is better anyway...

Comment 17

[David :Bienvenu]

fixed on branch (was never broken on trunk)

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified with version 0.9+ (20041110) from CVS.

Comment 19

[Scott MacGregor]

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

Comment 20

[Scott MacGregor]

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