Using jan24 commercial trunk build With today's build I'm seeing folder and newsgroup Bold attribute stick around within the session after all messages have been read. Have seen this on INBOX and other folders (filtered messages to other folders) and also on newsgroups after I've marked All read. It doesn't happen each and every time, but most times. Had seen this infrequently before today, but now it's happening with increased frequency. Similar kind of bug logged yesterday about deleting all messages (see bug 121469), but logged this separately since it didn't involve any deletions. 1. Open newsgroup, get new messages. 2. Mark all messages in newsgroup read. Result: newsgroup is still bold in the folder pane, although no unread count appears. 3. Open mail and get messages. 4. Mark All Read in folders where new mail has been delivered or filtered. Result: most often, folder pane will still show foldername in bold, no unread count.

fyi, I'm experiencing the same thing using the 1/24 trunk build. If you close then reopen mail, the foldername(s) will no longer be bold.

*** This bug has been marked as a duplicate of 94913 ***

This has been marked a duplicate of an older bug, but I believe something has happened recently to cause the increased frequency of the problem in the past couple days. may not be a duplicate.

I'm reopening this... the older bug is about bolding when new mail arrives and there's no apparent new mail to be found in the folder. This (newer) bug is about seeing the new mails and marking them read and having the folder remain bold. It happens on newsgroups consistently, too (no filter association).

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

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

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

according to reporter of bug 121987 this bug is now also in the 0.9.8 branch

It's definitely in the 0.9.8 branch. I'm stumbling over it all the time.

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

It seems these are all duplicate of thsi bug: bug 94913 bug 104463 bug 112466 bug 119627

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

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

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

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

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

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

Bumping up severity based on visibility and the amount of dupes.

Note, this bug is not only for mark all read - it's for a bunch of other cases as well. I suspect they are the same evil bug.

Then should the decsription not be a little more common like: Folders and newsgroups with no unread messages remain bold

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

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

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

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

accepting, investigating. this is a bad one.

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

Seth, I'll credit you 10 pushups if you fix this.

Seems to work correctly again using Build 2002020803 on Win98.

I 'm also not seeing this with 2002020803. What happens on other platforms/op.systems?

Linux; Mozilla build 2002020809 I am no longer seeing this.

W2K Build: 2002020803 I *DO* still see this problem.

In fact for Linux Mozilla 0.9.8 the bold highlighting of a mail folder remains even when normally reading all the messages in the folder. The highlighing is removed if the parent folder is closed and then reopened. Unfortunately this implies that the problem is now worse. I have not tried this with a WIN32 platform.

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

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

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

Problem does not occur anymore with build 2002021608 on win2k; bold disappears when reading last message and also if all messages are marked as having been read.

Is anyone seeing this problem with a current nightly build (20020218 or newer)?

i still DO see the problem, it does NOT occur when marking folder or newsgroup "all read". it happens when filters move/delete mails away from a folder: it stays bold, even when empty. i filed dup bug 124598 for this, and if anyone wants to have the usual steps to reproduce, please take a look there. 2002021903/WinXP

I am still seeing this bug on "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020218" Mark a newsgroup as read, or read all messages in newsgroup Close the newsserver tree ReExpand the newserver A few, not all newsgroups, claim to have unread messages (which they don't when you look) The same newsgroups are effected everytime.

I am no longer seeing this in commercial trunk 2002-02-18-03.

http://bugzilla.mozilla.org/show_bug.cgi?id=121660#c39 might be a different bug. I'm starting on this bug now.

ok, here's how I reproduce this in the Gecko/20020123 build: send myself mail that gets filtered get new mail, so that the filter target folder gets bold exit restart go into that folder, and read the message. folder stays bold. note, if I do all this in one session, it doesn't stay bold. now to try my fresh build.

Same as laurel, I'm not seeing this with my fresh build either. I wish I knew what changed to fix it, but it's probably not worth the time to track down when it got fix and then to pour over the checkins. about Josh's comment, I do believe that still is a problem. I'll query for that bug, to see if it already exists.

seth: the way you describe to produce this bold staying folder does not work for me. (2002022003/winXP) tried to do this in one session, but also quit the browser and restarted. target folder always gets normal after reading the message. But what I think is the actual bug, and what always does it for me (even in one session) is the following: you recieve a mail to you Inbox of you eMail adress; you got a filter sorting this mail to another folder, the source folder stays bold. (example: moving all bugmail to a mozilla folder) For me sorting bugmail from *Daniel.Steinberger@gmx.de/inbox -> *LocalFolders/Mozilla leaves the Inbox-folder bold. (Mozilla gets bold, too, but that's the way it should be) If I click on the Inbox now, it becomes normal, too, but I have to click on it to achieve this. This is the only bug I see here. REOPEN?!?

see dup bug 124598 for more detailed description of this behavior

an alternative to reopening this bug here was reopening bug 124598 which i sorted to MailNews/Filters anyway. please give a comment, or I'll just reopen my own bug, since this actually IS a reproducable problem and is very annoying.

ok, reopening. bienvenu's also given me a way to reproduce this: here's a way to reproduce it: mark a message unread in a folder (so there's just one unread) shut down. open 4.x, mark that message read. open 6.x up again, that folder will be bold, open it, it will stay bold even though there are no unread messages

i thought so ;-) well - anyway, something i was just thinking about: will your fix adress the filter issue, too? since i don't use 4.x, I can't test your steps to reproduce the problem and determine, if the 'boldness' will go away after clicking on the apropriate folder again. but i assume, it will stay bold when clicking on it, right? so i thought my move/delete-bug might have another cause. or do you plan to adress it too? if the cause is another, i suggest to reopen bug 124598. just give it a thought and drop a note on what you think. maybe this is complete nonsense?

something else changed recently (I'm guessing in the datasource?) which might be why it started working. even if I show all columns, my folder name contains the unread count. For example, my folder name is "xxx", it shows as "xxx (1)" in the folder pane, even if I am showing the unread column. I wonder if that regression has "fixed" this problem? I don't see bienvenu's or Daniel's problem, with my fresh build. I'll try the official opt bits from last night, too.

weird, that problem I just reported: "For example, my folder name is "xxx", it shows as "xxx (1)" in the folder pane, even if I am showing the unread column." doesn't happen for me if I have the columns shown at startup, but it does happen if I then close the columns and reopen them.

I see the regression Seth points out, but this bug happens to me anyway, starting up with the unread column on or off, doesn't matter (total column always on). This is with a brand new tip build as of 2PM today, 02/21/01

true: 2002022103 does not leave the inbox bold anymore. but something else still is present: when the filter moves the mail away from inbox, the little green arrow is still present at the accountname, you recieved the mail to. (see attachment 1 [details] [diff] [review]: screenshot) this way, bugzilla tells the user, he got mail, even after reading the new mail. (the biff-thing in the systray and the envelope with a green arrow in the taskbar indicate this) this indicator goes away when clicking on any subfolder of the mail account (inbox, eg.) shouldn't this also be fixed within this context, since there is no new mail, but mozilla indicates something different? or shall i file another bug for this issue?

The green arrow thing is treated as a bug of its own at the moment -> Bug 116181. Don't know how they are related.

my reproducible case now works for me, with a release build from yesterday (02/24/02), and with debug bits pulled from today's source (02/25/02).

so far, this is WFM for a few of us (sspitzer, bienvenu, laurel), but I'm not going to mark it WFM until we get more data points, or as bienvenu put it, WFE (works for everyone.) daniel, simon: is the "bold folder" problem still happening to either of you? the green arrow problem is another bug.

ok.. WFM, too. i already joined discussion on bug 116181 for the green arrow problem. but this one is WORKSFORME now. (fixed?)

Yes it works for me with todays nightly. 2002022506

marking as wfm, based on comments from laurel, bienvenu, daniel, and pratik.

marking verified worksforme.

Still happens to me in build 2002-02-25-03. A folder that is fed with mails through a filter, and that is in threaded view is still bold when all messages are read in it.

It still happens to me too with a 13 old-cvs. Same behaviour as Håkan Waara. The folder in question is the first subfolder of subfolder of an account i.e: My account |---Cybercafe |--- CC21 |--- CCTK |--- CCUX It happens for the CC21 folder but only after a new build has been installed.

Seems to be fixed for me in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020225. But it took some playing around. When I installed this newer version and opened the newsserver tree, no newsgroups that shouldn't have a new message were shown in bold, however when i selected the newsgroups one by one they would bold themself and list a number of non-existant new messages. With THIS build (and not previous builds) this could be permently taken care of by marking as read all messages. This means that the problem is not simply display but somthing with the storage of the .newsrc data as it was dirty from before. I used to try this all the time with older builds and it never fixed thre problem... I can't get it back into the state I had it in previously but I would warn that something is still not quite right, but it is probably a different bug and will be found more clearly. in some other context.

As said in comment 28, this is WFM for quite some time now. Now please fix this dam green arrow thing. ;)

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

So what are we gonna do about this? It still happens for both me, and as comment 61 indicates mozbug@durys.net too. Reopen?

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

Still happening here as well.. reopening. It only happens to one or two of my folders, and not every time a message is received. Deleting the .msf will correct the situation for a while, but it does continue to happen. I'm going to make a copy of the problematic folder, delete all messages and see if it continues. If it does not, I might be persuaded to attach the folder for inspection. Build: 2002022703 Win32

Is the problem that the RDF datasource is not notified/updated properly?

I still see this on a few of my many IMAP folders (WinXP, 2002022703). Not knowing what most of Mozilla's files are, I started playing around renaming random files/directories until the problem went away ;-) NB: my profile was created with an older release of Mozilla; profiles created with my current release don't have the problem at all. Turns out that renaming/deleting the 'panacea.dat' file in your profile directory fixes this problem for all folders (a new panacea.dat is created on mozilla restart). What is this file? Is renaming/deleting it bad? ;-) I took copies before and after. Should I post them here, or would that be useless?

good job, that would explain it. Yes, posting the "before" panacea.dat would be helpful (or e-mailing it to me). Panacea.dat contains summary information for all the databases (e.g, the total and unread counts for all folders). This info is stored in the individual summary files, but we don't want to open all the summary files to display the folder pane. What might be happening is that the panacea.dat file might not be getting committed at app shutdown all the time. This could cause problems.

Attaching 'before' version of panacea.dat, as requested.

OK, I'm reasonably convinced this is an outliner problem, or the xul outliner builder - we're notifying rdf of the hasUnreadMessages property change (both ways, -> false and ->true, doesn't matter) - the row is getting invalidated, but the bold attribute never gets cleared for the particular folder. I've stepped through the code a bunch of times, but I'll be damned if I can see what's going on.

Here's another way to reproduce the problem that I've seen twice now: startup mail, then the browser, then close the mail window and then biff fires and filters a message, and you open mail again, and go to the folder with the new message, read the message, you'll be in this state.

Seems to work mostly ok now on build 2002022808, was a lot worse on a build three weeks ago (the one default linked to on the main page for windows). I believe I have still seen the behavior once or twice though.

I wonder if this is related to http://bugzilla.mozilla.org/show_bug.cgi?id=99117 accepting.

not going to happen for 0.9.9, moving to 1.0

sorry, I'm not able to reproduce it on Linux

Still a problem on 0.9.9 - w2000. I've got IMAP account called SWH and then LOCAL FOLDERS. I set the filter to move some mail from IMAP INBOX into LOCAL FOLDERS. After arrival of e-mail which has been filtered, the SWH (the IMAP ACCOUNT) still remains bold despite of there is no unread message inside. Next (manual) check "unbolds" the Account.

Honestly, isn't #78 not in the scope of this bug? This bug was about a nasty problem where the folder would remain bold even after you manually marked all the messages read. This isn't #78 (which I see too).

Discussed in Mail News with Mktng, QA, Engineering and PjM. Decided to minus this bug.

This may be related to the bug where, if you are on the root of a newsgroup thread, and it has unread items (and so is underlined) and press R, all the items get marked read but the underline does not go away until you move off the message. Gerv

Don't see this anymore in Build 2002040103 winXP

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

I am seeing this regularly on winXP Gecko/20020426. I too have a rule that sorts mail to an offline folder, when i mark all read in the offline folder the folder name remains bold. If I click on the folder name at any time afterwards it goes unbold after about a second.

I'm getting this with RC3, with a POP3 mail account and mail filters, only when I have incoming mail to be moved according to filter rules _before_ the first "Get Msgs" after I start Mozilla. Folders bolded as a result of filtering newly arrived messages on the second and subsequent "Get Msgs"'s are correctly unbolded after I read the messages ; but the folder affected by the bug stays bold for the whole Mozilla session, even if I receive new mail in that folder later and I read it. Platform: Debian GNU/Linux 2.2 (Intel) ; Mozilla 1.0 RC3

It's not "Folder or newsgroup name left Bold after mark all read." - it's "Folder or newsgroup name GETS Bold after mark all read." what I did that evening: I thought, I should search the entry, for formatting "unread messages" in another colours, fonts,.... In a posting at a newsgroup I've been told to look up for treechildren:-moz-tree-cell-text(unread) { font-weight: bold; } With that information I tried different things at userchrome.css that won't lead to a result, that I expected or wanted to get After a while I had the idea, to look up in the source-files of classic.jar There I found a threadpane.css. Changes in that file had the same changes as result, like those made in userchrome.css But in the jar-file I found a FolderPane.css too. There I found under "all servers" the following entry: treechildren:-moz-tree-cell-text(folderNameCol, isServer-true), treechildren:-moz-tree-cell-text(hasUnreadMessages-true) { font-weight: bold; } YES - I found the part I needed to change for getting _only_ normal-weight text at the left side. It worked good, but then I marked all new postings "read" in different newsgroups: It's not been interesting doing that step by step or with ctrl-shift-C. The text of the group-name was getting bold _after_ the last marked posting. That's the reason why I think, that the bug-headline and our presumptions are wrong. The name isn't staying bold, it's _changed_ to bold. Perhaps someone can repeat my tests - or try better ones - for getting certainty

Certainly in my case groups stay bold. pi

In that example, I defined the folderpane at userchrome.css. You'll see that the definition will change from "blue on white, weight:normal" to "black on nothing, weight:bold" after marking all messages as read. The grey background-color I defined in the tree-element and isn't interesting for that problem. The cursor (red on yellow) is defined through the system-colors.

My impression is that the problem got worse in the last few weeks. Now folders (newsgroups not that often) stay bold many times. pi

Boris 'pi' Piwinger - did it get worse on the branch or the trunk? Which build are you using?

I'm using 1.1b (Gecko/20020805) at the moment. The testcase I've loaded up, was made with branch 1.0.0, I think (checking the day of my upload) I used different trunk-builds of july since the testcase. In my opinion it became better, but isn't disappeared yet. I'm watching the treeview and can see the bug for a short moment. When clicking on a newsgroup it get's black and bold (watch the colors of the testcase), but then I will see my blue on white again. But, when marking all new postings as read, I will be displayed with with 98% probabillity correctly black, normal. In that version (20020805) I had the effect not yet. I will tell, if it will appear in it or a later trunk-build Behavior of 1.0.0 was: showing that "change" too and getting black/bold after marking with 100%prob. - If there was no "change" recognizable when clicking on a newsgroup/folder of an emailaccount, it won't turn after marking the postings "as read". 'pi' is using 1.1b, 20020808 at the moment.. I can't write an answer for him - he has to do for his own ;-)

I saw it yesterday with my CVS trunk build (from yesterday)

RE comment 90: I only use trunk builds. I notice this problem for some days now with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/2002080820, previously with a version roughly a week older. pi

this bug is easy to cause if you open, close, and re-open your mail window - once you've done that, rdf seems to get confused and not update the boldness correctly. It does seem to have gotten worse recently, but that might just be because I've been opening and closing mail windows more often. When I traced this down, it was definitely something going wrong at the rdf/tree level

reproducing the bug with 1.1b: I'm still using the same version like in my last comment and the "hamster" (a personal newsserver) - fetching news with hamster - opened tree of a newsserver, not actualised/synchronized with hamster - click on a NG that contains _new messages_ and DON'T wait until mozilla has synchronized and fetched all new postings. - instead of waiting, you click another NG. The first clicked NG gets bold without showing the number of new postings perhaps it'll work with a direct connection to a "real" newsserver too, I've not tested it but: If I'm going back to the bold NG, mozilla will fetch the postings and shows the NG in "blue at white" like you can see in the testcase 2002-06-28. After marking all postings asd read, the NG will be shown the normal way. result: the bug still exists in 1.1b, but shows itself in another way

We missed the target milestone. The bug is pretty annoying. Do we know why those folder or groups remain bold? pi

Platform: Mandrake Linux 8.2, build 2002091016 When emptying trash (with unread mail) by hitting Alt-f y the trash folder line remains bold and the number of mails (total and unread) are not cleared. Selecting another folder, and then selecting trash again, removes the numbers and the bold aspect. Repeatable: always.

Anyone ever notice that it's always the first folder in a particular account that stays bold after all messages are read? That's how it is here anyway.

Also: if the folder that remains bold with no unread messages has subfolders, expanding the tree causes the parent (which shouldn't be bold) to go to normal status. Collapsing the tree brings back the incorrect boldness. Collapsing the entire account's tree and re-expanding fixes the problem. This happens in other ways aside from "mark all read", so changing summary.

For me its always the Trash folder and only the Trash folderm which indeed is the first folder in the account.

Actually, I see this happening for virtually every folder and newsgroup, definately not limited to the first. This includes post 1.2b versions. BTW: This is not a critical bug. But we certainly need to fix it soon. Maybe Seth can say what causes the problem or how I could help investigating. We have various bugs on miscounts. On or more of them might cause it. E.g., I see the unread count disappear even though there are several unread messages. Later the group may stay bold or not. pi

Shot of bold weirdness when expanding/collapsing affected tree.

Jerry, that's very interesting. I'm not sure if expanding the folder causes rdf to refresh some state, but the fact that collapsing it restores the boldness makes me think that the problem might be related to the code that looks at sub-folders to decide if they have any unread messages and sets the parent to bold if it thinks the sub-folders have unread messages. I think I've only seen this bug on parent folders, so that might be a large factor in this bug.

I don't know if it's separate code or not, but this regularly happens to one newsgroup I read also. The group is the first in that news account, and it doesn't have subfolders (obviously). The only thing I can think of that is different on that account is that I have biff turned on for that server. The other groups on that server are not affected.

Actually, what Jerry is seeing is desired behaviour (I think it's a bit odd myself, but it is desired behaviour for a collapsed folder with children with unread messages to show up as bold). But, I think it's also related to the cause of the bug - what seems to happen is that if you start up mail, get messages, read them, open a browser window, close mail, and then have biff fire and retrieve new mail, then open the mail window again and read the new messages, the folder will remain bold. On a tip from Seth, I changed it so that parent folders with children with unread messages show up as italic instead of bold, so we can tell the difference between a folder which we think has unread, and a folder which we think has children with unread. And it turns out that we think the folder has children with unread. So I'll look further into what exactly is responsible.

How are you getting biff to get mail without a mail window open (bug 71105)? Anyway, there are no unread messages in any of the child folders in my example, so the behavior is not desirable whatsoever.

the problem was that the code that asks if child folders have unread was including the parent folder in that calculation. The fix is to subtract any unread messages in the parent folder from the total unread in children.

if you start mail, then start the browser, then shutdown the mail window, biff will still fire (at least for imap, and I believe for pop3 as well).

Not for pop3

address Seth's comment.

caused by my fix for #19254 (from 10-9-01), so it's been broken for a year. thanks for fixing my slop, david! sr=sspitzer, once you move the declaration of the PRInt32 into the if block

Is this the only cause of the folders remaining bold? In the example I put here, every child folder has zero unread, and the parent has zero unread. Subtracting zero from zero will still leave you with zero, as will adding them. How was Mozilla getting something > 0 when there were zero in the first place?

david is going to attach a patch that also makes sure count is > 0 before subtracting.

we shouldn't do this if the unread count is negative (which means we don't know if it's unread or not).

Comment on attachment 104298 [details] [diff] [review] patch addressing Seth's comment over aim sr=sspitzer nice!

Jerry, it's kind of complicated, but I'll try to explain it. Keep in mind that bold on a collapsed parent folder means either the folder itself has unread messages, or child folders have unread messages. Those are two separate attributes on the folder, both of which end up displaying the folder as bold. What was happening was that getting an unread message in a parent folder could cause *both* attributes to get set. Reading a message in the parent folder would clear the first attribute, but leave the second attribute set, so we'd still display the folder in bold, even though, as you say, there are no unread messages in the folder, or in its children. What my fix does is make it so we don't set the "has children with unread msgs" attribute on the parent folder if we build up the rdf node when the parent folder has unread messges. I can't promise that this fixes the problem for all situations, but it sure fixes it for the reproducible case, and we'll have to see if it fixes the other cases as well.

Comment on attachment 104298 [details] [diff] [review] patch addressing Seth's comment over aim Please initialize numUnreadInFolder and r=rdayal.

Ok, I see. The only other case that I have is a newsgroup that remains bold after reading all the messages. It is the first group in the tree. That account has nntp biff turned on (dunno if that matters). I imagine this won't fix that, but I'll get a download after this patch makes it into the trunk and give it a go.

Comment on attachment 104298 [details] [diff] [review] patch addressing Seth's comment over aim doesnt need to initialize the var in this case since the called function takes care of setting the var correctly as discussed over AIM with David.

bienvenu sent mail to drivers, hoping to get this into 1.2 final

Comment on attachment 104298 [details] [diff] [review] patch addressing Seth's comment over aim a=roc+moz for trunk

fix checked into trunk.

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

Update: I am no longer seeing this bug using last several days' commercial trunk builds. I had one windows profile where some folders would always catch this condition. That profile is OK now. I have not seen on any other profiles/platforms. Since this was such a popular problem, I won't mark this verified until we have some more time with it. Will wait for awhile to give folks a chance to comment, confirm the fix.

This is the inbox folder of one of my acounts. Emails have been imported from outlook. They were all showing as new mail (normal behaviour). I selected them all (CTRL+A) and marked them as read. All the mails then lost their bold attribute, but not the folder. The picture shows 19 new emails. If I receive a new one, this is updated to 20. If I then read the new email, it goes back to 19. So it is working fine for new emails. If I restart Mozilla, I still get the same problem. Config: WinXP Mozilla 1.2b Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016

that's a different problem - we think you have 19 unread messages - notice the count is still 19. When did you import these e-mails from outlook? I suspect that they were imported when the import tool did not add an x-mozilla-status line to the messages, which makes it hard for us to keep track of whether they're read or not. You're using POP3, right?

I haven't seen the problem as originally reported in latest commercial trunk builds using win98, linux rh8.0 and mac 10.2. Marking verified.