Open Bug 438257 Opened 16 years ago Updated 2 years ago

[meta] incorrect new and unread indicators and count

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
All
defect

Tracking

(Not tracked)

People

(Reporter: ovidiu.grigorescu, Unassigned)

References

(Depends on 6 open bugs)

Details

(Keywords: meta)

This is a meta for gathering bugs on incorrect display of new and unread indicators or count numbers. I just see a bunch of bugs on very similar issues on these that are spread around with some variations. But variations do describe different behavior, so not duping them. I'd treat them together though some may eventually be different. Grouping here may refer to dupes but not always. 1. general [or with links to alike] Bug 261201 general one with links to others (been a candidate to meta..) Bug 324375 also with links to others Bug 377483 various errors like in the following ones (this gets full treat..) 2. on filters "move,mark read,delete,tag" bug 249271 (source still highlight) bug 437612 (same? source still highlight) bug 414106 (guess same, involves junk, auto compact?) bug 316946 (on startup) Bug 337331 (target not highlight) Bug 316768 (same target highlight) Bug 392637 (filters tagging) 3. on action "read, move, mark as.." (or just like that) bug 381017 (good one, negative nr) bug 347073 (on folder del +recreate) bug 352080 (not updating ..) Bug 420865 (not updating, also tray ..) bug 260133 (not updating if subfolder moved..) Bug 232967 (on change to folder..) Bug 341511 (ugly, and old) Bug 377400 (about trash) Bug 420173 (also on trash, few info) Bug 370409 (same as "auto compact" above? but more weird ) Bug 362220 (general erratic) bug 274688 (dock, but related) Bug 312292 (no reason ..) Bug 369749 (seams no reason ..) Bug 313056 (new not show in parent-old?) Bug 382975 (same name folders) 4. huge or raising unread numbers Bug 295667 Bug 332585 Bug 289674 Bug 326631 (also on total) 5. on shared folders bug 283756 (far) 6. search Bug 304190 search Bug 305902 search Bug 300487 search 7. imap (these may be different) Bug 328893 search and imap Bug 379931 filter and imap Bug 422729 imap Bug 370384 imap bug 331970 imap subfolders new/unread confusion bug 332697 same imap subfolders new/unread confusion Bug 432845 imap (another negative nr) Bug 370914 imap .. 8.on feeds (that's a bit different?) bug 359974 bug 260545 adding rss 9. on news groups (gosh I know these ..) Bug 79130 bug 356537 bug 295381 10. others bug 377507 account level
I've been actively working this area for the last few weeks, specifically with respect to saved searches. Issues with counts in searches that do not involve flags (such as tags or junk fields) is bug 428427. I've also been looking at similar problems involving MSG_FLAG_NEW in bug 372372. At the moment, I consider bug 116181 the mother of all new count bugs. The fact that there is no overlap between the bugs I am actually working on, and the initial bugs in this list, I guess shows that there are many, many bugs that deal with similar issues.
added kids and the mother in dep. If you're onto this, would you check those in "search" ? or against mommy. Does ssearch imap differ? (As you can see, from a certain point is hard to distinguish, though situations seams bit different. ) Maybe is just a case where people tend to detail better or is just easier to "see" the scenario..
Depends on: 116181, 372372, 428427
(In reply to comment #2) > > Does ssearch imap differ? (As you can see, from a > certain point is hard to distinguish, though situations seams bit different. ) > Mostly the issues I have been looking at are not specific to IMAP, as IMAP generally uses the same code for search as does local accounts. For counts though it is a different story. I've not really started looking at IMAP count issues yet. New and unread are implemented really quite differently, so those issues are often unrelated. New in particular is quite a mess right now, with portions of the implementation spread between the message header, message database, and folder code. You're right that it is very hard to distinguish the different error reports from each other. It's often easier for me to define a new bug, as in bug 428427, that describes the particular problem that I want to fix. I think it will be easier for now to fix some of the problems, then go back and check the bugs to see which ones have gone away. Well-defined steps to reproduce are always appreciated in the bugs, as that makes it easier to find and verify fixes. In particular, each search term and action has its own sets of issues, so a report with a vague "I created a filter" type of report is hard to pin down.
In dev ng davida suggested a better use of a whiteboard (as keyword actually..) to gather stuff like this instead of meta. I tend to agree as this was just a workaround for : -bug searches, in this case too may variations in names etc -grouping by feature/narrow area, as a sub sub component -proposing focus /temp alternative Also, this is the kind of meta not created for work on/ follow/ track which is not good. Would a whiteboard "unread_count" do?
(In reply to comment #3) > New and unread are implemented really quite differently, so those issues are > often unrelated. well, they do appear in some of these bugs together. And it's obvious that a reporter cannot always make difference, to split new indicator/ unread indicator/ count nr issues (even mix up terms sometimes)
No longer depends on: 295381
No longer depends on: 79130
removed ng issues as they are tracked in bug 71728 (and usually less related to other new and count stuff)
No longer blocks: 79130
Depends on: 79130
argh, sorry for bugspam, didn't notice Comment #6 until now. :(
No longer depends on: 79130
Depends on: 438242
Depends on: 440810
More virtual folder (search) bugs that should be added: 328893, 365392, 443753. What a mess!
Depends on: 492302
Depends on: 382977
i have been running tb 3.1 for a long while and am now on miramar 3.3a3. what i'm running into is the saved search (sources: imap, rss) not refreshing itself consistently. even though i am seeing respective imap folders having new messages, my saved search folder just idles on. inconsistency = sometimes it does refresh itself, but i am not able to find a solid pattern when this does or does not happen. saved search criteria includes: tags, age switching to another folder and back refreshes the contents correctly. bug 267997 feels close to heart, until this thing somehow resolves itself. this obviously means thunderbird knows about the messages but propagation or reacting to this knowledge fails somewhere. i am not sure what to do with this issue. does it belong to a bug that is related to this metabug, or is there another larger metabug that handles saved search issues that are a level lower of just incorrect counts? i.e. in my case the counts are actually correct since saved search is not seeing the new messages, which otoh is the problem itself.
Depends on: 531251
Depends on: 1571070
Severity: normal → S3
Depends on: 1738948
You need to log in before you can comment on or make changes to this bug.