Closed Bug 518828 Opened 15 years ago Closed 15 years ago

Need a new preference to allow "New Mail" count for dock icon instead of unread mail count

Categories

(Thunderbird :: OS Integration, defect)

Product:
Thunderbird
Component:
OS Integration
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-thunderbird3.1 beta2+, thunderbird3.1 beta2-fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking-thunderbird3.1 --- beta2+
thunderbird3.1 --- beta2-fixed

People

(Reporter: omnichad, Assigned: accounts, NeedInfo)

References

(
URL
)

Details

(Keywords: uiwanted, Whiteboard: [UXprio] [gs])

Attachments

(3 files, 8 obsolete files)

dock options
73.84 KB, image/png
Details
mockup of the dock options preference
96.00 KB, image/png
Details
hidden preference patch, v2
5.78 KB, patch
dmosedale
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1) Gecko/20090806 Namoroka/3.6a1 Build Identifier: The dock icon has been changed to show unread messages instead of "new" messages. This is a loss in functionality for many of us. The behavior was working fine for me before, and the old way should be maintained — at least as a preference. I leave messages unread if I know I can't deal with them right away, and I'm sure other people do the same. I use the dock icon to keep track of how many messages have arrived since I last looked at my mail. One of the bugs filed to get this changed mentioned how hard it is to answer the questions of "Since X" - that is, how many new messages since what event? I think the answer to that is whatever makes an inbox turn blue. The code must be there already, so why can't we use it for the dock icon? Reproducible: Always
Version: unspecified → 3.0
As I just told you in the previous bug, this was discussed in bug 274688. If it makes you feel any better, I actually preferred the behaviour you describe. However, after much discussion and debate, this new behaviour was chosen in order to match what users expect from other applications. My own view has since changed, after writing and now using the new code. I'd suggest you spend some more time with it, too. This debate has already happened, and this is the decision that was reached by the community. Marking WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
That wasn't much of a debate. It was more just you chiming in repeatedly. The rest of the "community" in that discussion seemed evenly split about 50/50. The fact that you chose to ignore it doesn't mean that there isn't a significant user base that cares about this as a bug. The impression I got in reviewing the other bug was "Ooh, this is hard. And since other people want unread, let's just ignore this entirely." And yet a user pref was added to distinguish between Inbox unread and All Folders unread. Because it was easy.
Status: VERIFIED → UNCONFIRMED
Resolution: WONTFIX → ---
Being insulting is not a great way to get action on your bugs, fyi. I didn't "chime" in, I took a bug that was getting no attention from anyone, and fixed it. The fix was the one described by TB's UX lead (see bug 274688 comment 48). You might not agree with it or him, and that's why we have extensions. I'm not interested in being dragged into this. Making a decision will always result in some people not liking the outcome. In future, if you want to be a part of such decisions, get involved in bugs as they are happening.
You made the claim that it was a full debate, and that there was a community consensus. I don't see it. That's not an insult. I'm only telling you what I saw.
I'm sorry to anyone I might offend, but since when was the Thunderbird community limited to a couple of core programmers? Or just programmers? Now that the feature change is in userspace via the beta, it warrants a bit of revived discussion. I'm not saying that the work that went into fixing the message count is a waste. It's also a needed feature in its own right - but there are a few fundamentally different ways of using an inbox. This is now the only one I can think of that isn't handled. Copying functionality from other email programs is good and all, but the "new mail" feature was an innovation. Innovations aren't always the *most* intuitive. Given that there are prefs for lesser ideology differences, I am going to defend this bug.
Keywords: common-issue+, uiwanted
Chad, I can understand where humph is coming from, having just gone through a bugzilla marathon myself (bug 462578) where we never fully satisfied all commenters, and I just wanted to get the darn problem fixed. But at the same time, (and declaring my bias as pro-NEW flag), this does warrant more discussion, and that was even suggested in early reviews of humph's bug ("In general this looks good, and I agree we should give the new numbers a try and see what folks think." in bug 274688 comment 44). But what's done is done, and now the need is to define a next step. As a first step, if a hidden preference could be supported that uses NEW instead of UNREAD counts, that would help. That is all that might be reasonably accomplished before TB3, and even that is doubtful. If you could redefine this bug to suggest something specific and doable, it would help. But I must warn you that the NEW counts themselves have issues that need fixing, so it would be very hard to get NEW counts to work as reliably as UNREAD without some refactoring (bug 507638).
rkent, is it possible for you to help me out? This is probably my first attempt at *posting* a bug, but not my first time using beta and alpha Mozilla code and far from my first time searching Bugzilla. I am not sure of the wording change needed. My summary displays the issue, but I don't know what is unclear that warrants a new filing. A hidden preference is probably all I could hope for, and I agree. Is there any possibility that the logic used for making inboxes display in blue could be re-used for this purpose? Or is the fact that it's not count-oriented make it a silly suggestion? I am the exception, in that I don't use any mail rules (except junk), and no smart folders, so I don't know all the complexities involved. I would be satisfied with the buggy old behavior for myself - but I can see why it had to go. For that matter, I'd be fine with a non-numbered green circle that says I have "NEW" mail that disappears when I look at the folder.
Chad, there's always a tension between bugs that are from the user's perspective, or the developers perspective. My own bias is to take bugs that start from the user's perspective and morph them into the developer's perspective, but that is by no means universally accepted. Anyway, what I would do is to change the description away from being a complaint about program behaviour (which was fine to begin with, BTW) and change it to the specific request to add the hidden preference. That bug would be much harder to WONTFIX than a complaint about a previous decision, as the bug currently reads. The hard part though would be to get a Mac hacker to actually do the change on a rush basis. Humph would be one choice, though you have not exactly endeared yourself to him so far. My understanding is this is Mac-specific behviour, so I can be of no help here.
I was under the impression that there was something equivalent on all platforms, and the display logic isn't really relevant here. Am I wrong?
Summary: "New Mail" count on dock now reflects ALL unread messages → Need a new preference to allow "New Mail" count for dock icon instead of unread mail count
(In reply to comment #9) > I was under the impression that there was something equivalent on all > platforms, and the display logic isn't really relevant here. Am I wrong? Windows has no permanent count, only a popup that displays when messages arrive. My understanding is that most of humph's work was directed at the Mac platform, which is one reason that I did not follow it closely. The Windows version also works bady, so that I pretty much ignore whatever it says there.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hi, For whatever it's worth, I'm with Chad on this one. Even if the system to determine whether there's new mail was broken in some way, it's never bothered me, and it's always been far more useful than the unread count I'm getting now. I've spent a few days with it, and it's definitely not grown on me... (in fact now I've learned to just ignore the number and go and manually check my mailboxes whenever I want to see if there's anything new). I guess my take on this is that any previous discussion on whether to have an "unread" vs "new" count was mostly conducted by people who wanted the change to an "unread" count, since people like me who were just happy the way things were had no reason to be on Bugzilla. It would be great if we could have some sort of poll on this, but that's obviously an absurd suggestion. Pretty please could we have a little switch, hidden or otherwise, that reverts to the old behavior? I hope that's not too much to ask... Many thanks! Svet
Same sentiments as Chad and Svet here. It's an irritation that I either have to mark all spam as read or totally ignore the counter in the dock.
The common-issue keyword is used by Firefox Support to flag issues we see a lot on SUMO and get dev attention. We're happy to share but we should probably talk about the best way. I'm going to remove the keyword for now until we figure out a way to use them for other projects.
Keywords: common-issue+
I noticed this change with the new SeaMonkey 2.0. I miss having the new mail indication as well, because right now, I'm showing over 2,000 unread messages. The growl notification is nice, but if I'm not looking at the screen or wander away for a bit, I have no way of knowing I've received new mail without checking MailNews. (I'm assuming this change comes from a common code base between Thunderbird and SeaMonkey MailNews. If not, let me know and I'll keep browsing bugs or open a new one.) If we're concerned about accurately counting new mail, how about just adding a new mail badge/indicator to the dock icon in addition to the unread mail count?
Any chance soemthing will happen on this issue before TB 3.0 final. The new behavior is really distracting, I'd rather turn the indicator off completely now. My unread count is in the 4000's . I don't really want to mark mail as read that I don't want to read.
It's pretty clear from discussion elsewhere on the internet that this new behaviour is nonsensical to a lot of people, so I've added a vote to this bug. It's unfortunate that decisions like this get made where a behaviour changes quite radically rather than an option being given. I can somewhat understand from a programming perspective why this is done, I guess. Via bug #534098 I discovered I had mail.biff.show_alert set to false presumably for some no-longer-relevent reason, so at least I will now have the dock icon bouncing to tell me there are unseen messages.
Now that I've seen it in action, to be honest the dock bounce is really not enough. It just bounces a couple of times. If I don't remember that I have, say, 6 messages that I've currently left unread, there is nothing remaining to make it clear that I actually have an unread message. Same in the inbox, for that matter. In previous versions, unseen messages have an additional visualisation which is now gone.
In terms of the color it would be nice if it could be adjusted using userchrome.css or usercontent.css.
I agree with the people saying that the new behaviour is annoying. Please let an option to restore the old one! I don't see any reason for NOT doing it. Thanks!!!
I've read the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=274688, and it shows two quite different views for the dock icon. Thus, red and green seem good choices for what could be two different options. It would also become a feature to choose Thunderbird over Mail.app. Until now, I knew that a green zero meant new filtered mail, and any other number would mean a number of pending (and possibly urgent) messages. In my opinion, accuracy is not important in the dock. I've downgraded, even though there are lots of very useful improvements... which I don't see all the time. Thanks for the hard work, in any case.
Flags: blocking-thunderbird3.1?
I'm voicing my support for bringing back the previous behavior. What's the point of having that dock icon always show a red flag with some number? So now I have to look at it and do some mental math to see if the number has changed from before to tell if I have new mail? What's the purpose of having the badge then? For the people who's in pro the new system, what was wrong with the old? It wasn't like the dock icon wouldn't show you when you had a new message. It was just smarter to not count a message you had intentionally marked unread as a new message. Someone posted a screenshot where their dock badge showed over 500+ messages. I regularly read my emails and mark some as unread so I remember to get back to them. Tags don't work - if you mark something as "to-do" or "important", it doesn't change the left hand folder view. Whereas when you leave something as unread, the folder will be highlighted in bold and have a number next to it. It's a very useful way to know there's something still in that folder you need to follow up on. Thanks to this new behavior, I have to mark every new message as read so I'll actually be able to rely on the dock icon to tell me when I have a new message. Someone explain how this is better...
The previous behaviour was also good for showing how many new messages were waiting on the server, for when you set it to NOT automatically download new messages. In its current form you have no idea how many are waiting to be downloaded.
I agree with the Thunderbird 2 behavior as preferable. I don't mind an option for supporting both, but I receive a great deal of messages I never read or delete and if I must have a notification added to my dock icon, I would prefer it be how many messages have come in since the last time I looked at my in box or folders. With the only behavior supporting listing unread emails you really limit the usability of the status update. I am sure some people open and tag every email they get, but others like to keep some messages unread and they would like to exclude them from the dock count. I hope the amount of feedback on this issue prompts the restoration of originally function or a solution that supports either.
I created a Bugzilla account just to vote and track this. I've been a loyal Thunderbird users since 2003 in the 0.1 days, and this is such an annoyance, it's almost enough to make me migrate 10+ years of messages to mail.app. Happy to beta/alpha/pre-alpha test. *Any* sort of preference (unofficial, undocumented, unsupported, pref hack, I don't care) would be an improvement to having to change my reading behavior, and I refuse to auto-marking spam as read. Seriously, if we don't have traction by this January, I'm either downgrading or going w/ mail.app, as much as that pains me to say.
I also created a Bugzilla account to say that previous behaviour was ok for me. Please let user decide in user preferences to count "new mail" in green circle, count "unread" in read circle or both. And please also let user config to consider unread/new mail "only in inbox" or wide in all folders Thank you very very much
At the moment my Thuderbird shows 23230 unread email which is totally nonsensical. Even though I love Thunderbird and install it on all my machines as one of the first items, this change really does not make sense to me. I do not consider myself a Mozilla developer at all, more an everyday user of this mail software. For the purpose of voting and to voice my disapproval with this new feature I have created an Bugzilla account and strongly urge the developers to find a solution to this issue. Thanks so much for reading and acting on this bug.
This comment is primarily aimed at drivers. I'm requesting blocking-thunderbird3.0 for this. It does not really affect me, but I've followed this issue since it represented a move away from the "New" flag, and I am generally a booster of the New flag and friends. This bug has generated a significant number of votes in a short period of time, which is indicative of the pain it is causing for some loyal users. I have not looked at the underlying code, but AFAIK it is fairly simple to substitute the new count for the unread count. So a hidden preference could probably be added fairly easily, without causing localization issues. I think that should be made available soon on the branch. For 3.1, we should really consider adding UI for the preference.
blocking-thunderbird3.0: --- → ?
I agree w/ kent. I think in 3.0.1 we should have a hidden pref, and we should start talking now about what to do in 3.1. Kent, would you have the time to do the 3.0.1 patch?
blocking-thunderbird3.0: ? → .1+
Flags: blocking-thunderbird3.1? → blocking-thunderbird3.1+
The issue is that this is a Mac-specific patch, and I run Windows. So I am not a good candidate for this.
Some notes: - with new "unread mail" mode, please consider also to count unread mails from all folders: they are not considered if moved by filters/rules - this "bug" is marked as "x86 Mac OS X" but I think is the same on PowerPC Thank you all for your support: this is possible only in an open source project and I like it very much.
Marking as "all Mac OS X" as this affects PPC as well
Hardware: x86 → All
I also would like to voice my support for the old behavior of Thunderbird 2. My dock icon shows 2,638 and it is no longer useful to me. Please fix this behavior or add an option as soon as possible! Green was also a better color.
Well, I had some free time, and I am a software developer.. so I decided that I would try fixing the bug myself! :-) Bear with me though, because this is my first bug fix I've ever done for Mozilla. Here is a patch that I came up with which reverts Thunderbird to its previous behavior if a hidden preference: mail.biff.use_new_count is set to TRUE. It will display only how many newly received emails you have, and when you read one of them, the count will go away, like it did in Thunderbird 2. It still uses the red color if you are running Leopard or Snow Leopard, because the code makes use of an OSX API which uses the standard color red. If you are on Tiger, it will display green. I've tested it out, and would welcome the more seasoned programmers to check it out and see what they think!
Sorry, the code formatting on the other patch didn't adhere to the standards. This one is better.
Attachment #419219 - Attachment is obsolete: true
Patrick, please read https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements for the patch review process. You have to ask for review on your attached patch by setting 'review' to '?' and filling in a proper reviewer.
Thanks Martin - I fixed a little whitespace issue, and marked this one for review: ? dmose@mozilla.org.
Attachment #419234 - Attachment is obsolete: true
Attachment #419249 - Flags: review?(dmose)
I also registered just to vote on this issue, adding an option/hidden pref/etc. to revert to the TB2 'green' behavior. Thanks Patrick for your effort on the patch. I could probably spend an afternoon trying to figure out how to patch and compile the source, but will just stay on TB2 until this issue is integrated into a build (Hopefully 3.0.1!). Thanks to all the developers for building a great product.
Just adding my two cents in favor of having a preference to enable the TB2 behavior. Anyone on the development side have any guess when this will get into a full release?
Blocks: 537437
(In reply to comment #39) > Just adding my two cents in favor of having a preference to enable the TB2 > behavior. Anyone on the development side have any guess when this will get > into a full release? I think this has a good chance of making 3.01, which should release before the end of January. It is already approced for that release.
After having used thunderbird with my patch for a week, I came up with an improvement. The old patch would only reset the new count if you read an unread message. This is annoying if you don't actually want to read the new mail you got. Now it follows the same logic as what turns your inbox from blue to black. Basically when messages are checked and there are no new ones the count is reset.
Attachment #419249 - Attachment is obsolete: true
Attachment #419759 - Flags: review?(dmose)
Attachment #419249 - Flags: review?(dmose)
I couldn't resist tinkering some more.. I know a lot of you liked the idea of red means unread count and green means new count. In the original patch I just stuck with the red provided by Leopard's API call. Now I have it drawing the old way in green if you're using the new count.
Attachment #419759 - Attachment is obsolete: true
Attachment #419764 - Flags: review?(dmose)
Attachment #419759 - Flags: review?(dmose)
No longer blocks: 537437
Blocks: 537437
No longer blocks: 537437
Blocks: 537437
Attachment #419764 - Flags: superreview-
Attachment #419764 - Flags: review?(dmose)
Attachment #419764 - Flags: review?(david.humphrey)
Comment on attachment 419764 [details] [diff] [review] If a hidden preference is set, the dock icon will show the green new count instead of the red unread count I think humph would be better reviewing this patch as he wrote the unread mail code in the first place (and Dan may be backlogged for a few days). You'll also need superreview for this (which I can do). However, I don't like the way you are reverting to the old API to get back to the green colour - We specifically changed the API on 10.5 and later due to reported memory leaks and the advice in the Mac developer documentation. If the red isn't liked, then a new bug should be filed on that and if it is agreed that it is wanted, a solution found with the 10.5 APIs (if there isn't one, then maybe the Mac OS developers need contacting to get an extension to the API so it can have a different colour). Therefore denying superreview due to the way you're changing back to the old API to try and get around the colour issue.
(and I totally forgot to say, thank you for working on this - it is very much appreciated).
Assignee: nobody → accounts
Hi Mark - thanks for your feedback and offering to superreview. I backed out the color changes and uploaded the latest patch.
Attachment #419764 - Attachment is obsolete: true
Attachment #419891 - Flags: superreview?(bugzilla)
Attachment #419891 - Flags: review?(david.humphrey)
Attachment #419764 - Flags: review?(david.humphrey)
(In reply to comment #43) > If the red isn't liked, then a new bug should be filed on that and if it is > agreed that it is wanted, a solution found with the 10.5 APIs (if there isn't > one, then maybe the Mac OS developers need contacting to get an extension to > the API so it can have a different colour). I fully support having a different color for "new mail count" vs. "unread mail count". It this helps remembering which option is on when using TB on different machines/in different work environments (especially if you have to switch between TB2 and TB3). Signification of this single number is ambiguous, but color would remove the ambiguity.
My two cents...I have no preference on the badge color or even having a number in the badge (since the blue font in the folder view shows where the new messages are), just so there is a visual notification in the dock that new messages have arrived since I last checked. Unrelated, but the 'unread' badge in TB3 didn't show the correct count for me earlier (badge said 12, but only 6 unread across my mailboxes).
Well if you believe that the crucial information is whether new mail has arrived or not, then a potential solution is to change the icon itself to indicate new mail, and leave the badge as it is. It is a simple way to solve the issue BUT in this case the badge should be optional, as it is frankly annoying to people who for a (sometimes good) reason have load of e-mails marked as "unread" -- there's no point in knowing you have 2051 apparently unread e-mails. With this latter solution there wouldn't be any ambiguity in mixed environments. And it's certainly easier to implement, as apparently the 10.5 API doesn't give you any way to alter the badge color (well I couldn't find any). I've a problem with this approach though. As previously emphasized, a green zero can tell you both that new mail has arrived AND that it's been filtered out. In this case this new mail is likely not worthy of your immediate attention. If you're expecting an important message then it may be useful to check for misfiltering though. In short, the green zero is more informative than a simple indication that new mail has arrived (or no indication at all if it was filtered out).
Setting to needed as we're not going to hold .1 for this, but we still want to get it into the 3.0.x builds.
blocking-thunderbird3.0: .1+ → needed
The most important thing for me is that the icon badge should (optionally) behave like Thunderbird 1.x/2.x. Fact is, people like me have been watching that icon out of the corner of our eyes for 8+ years and our muscle memory is pretty strong.
Ok, it seems that there is a consensus to the fact that there should at least be an option (and in this thread, I'm pretty sure everyone would revert back to the original behaviour of TB2)... now, there's a patch developped.... how the heck do I apply this patch to my TB3 ? This new behaviour really is a deal breaker for me and I've kept myself from switching to TB3 simply because of that.
Hi Maxime, unfortunately the only way to apply the patch is to download the source code, apply the patch and build the executable. You need to download some tools first to set up an appropriate developer's environment. Hopefully the patch I made will be reviewed soon and can make it into one of the next minor versions of Thunderbird. That will spare you all of this needless trouble. Is there any other developer who would like to review it? It would be great if Humph could, but he is the one who said he wouldn't touch this bug after spending a lot of time with the other bug that called for TB3's new behavior.
Comment on attachment 419891 [details] [diff] [review] If a hidden preference is set, the dock icon will show the new count instead of the unread count Thanks for the patch, it's looking pretty close. A few issues with it, then some general comments to follow. >+ else if (aNewValue == nsIMsgFolder::nsMsgBiffState_NoMail) nit: trailing space >+ mUnreadTotal += difference; >+ nit: extra indent whitespace >+ // Do the same for the new count, but if the difference was negative, that means nit: trailing space >+ mNewTotal = 0; >+ nit: extra indent whitespace >+ // Use either unread messages as the count, or new messages as the count, depending on the preference >+ nsresult rv; >+ nsCOMPtr<nsIPrefBranch> prefBranch(do_GetService(NS_PREFSERVICE_CONTRACTID, &rv)); >+ NS_ENSURE_SUCCESS(rv, rv); >+ PRBool useNewCount = PR_FALSE; >+ prefBranch->GetBoolPref("mail.biff.use_new_count", &useNewCount); >+ >+ // If count is less than one, we should restore the original dock icon. >+ if ((!useNewCount && mUnreadTotal < 1) || (useNewCount && mNewTotal < 1)) Checking this every time we badge is probably not the right thing, since we can only do unread counts properly if we do it from startup (i.e., we walk all folders for an initial count on startup, then keep a running total, so switching requires a restart). I think moving this to ::Init makes more sense, and add mUseNewCount. Also, watch the extra indent space before your // If ... comment. Another issue I notice is that you haven't dealt with the startup badge count. You'll notice in ::Observe I do that count when we get "mail-startup-done." You can solve this problem with the fix above, and only do that unread init if mUseNewCount is false. It might be good for those in this bug who want this to try it out and see if it is actually what they want. I mention this because this patch won't work exactly like the old code. In TB2, which was badly broken, we showed the number of messages that were received with the first biff, and then it never changed. This code is a nice improvement on that, but my own experience working on this part of the code is that you simply cannot make everyone happy. I suspect you'll hear the same. My final comment on this patch, and following from what I've just said, is that I really think this should be an extension vs. something we do in tree. We have a hook already to make this possible (i.e., you can add an observer for "before-unread-count-display" and set the count to whatever you want). I'll let Standard8, or whoever you use for SR, make a decision.
Attachment #419891 - Flags: review?(david.humphrey) → review-
Can you explain in which situation was the code in TB2 broken ? I don't understand what you mean by "we showed the number of messages that were received with the first biff". From my experience, in TB2, a little tag appears when I receive new messages. When it checks for new mail, if it gets 5, it'll show 5. If it gets 2, it'll show 2. This seems to be the expected behaviour. Do you mean that if you did get 5, and then, before reading them, you get another 2, it would not update it to 7 ? If this is what you mean, I agree it might be seen as a bug. I think everyone will agree that it is even better if it shows 7 in that situation. I don't think it was a very bad and dangerous bug though, because in the end, what is important is that it tells us that we have new messages, whatever the count is.
and, about the idea of making it an extension vs a patch. I would be fine with either, as long as it doesn't delay the implementation anymore. I am restraining myself from using TB3 because of that single "bug" (to me, it is one). And I know of at least one other bug that was corrected between TB2 and TB3. So I have to pick the lesser of two evils.
(In reply to comment #54) > Can you explain in which situation was the code in TB2 broken ? I don't > understand what you mean by "we showed the number of messages that were > received with the first biff". Biff is a folder state, not really useful for anything other than internal code. It gets set under certain conditions (e.g., new mail arrives the first time) and also gets cleared by various conditions (e.g., you interact with the UI). It's not the same as what a user means by New or Unread and this is the reason for confusion. > From my experience, in TB2, a little tag appears when I receive new messages. > When it checks for new mail, if it gets 5, it'll show 5. If it gets 2, it'll > show 2. This seems to be the expected behaviour. In TB2, when you get mail the first time, and you get 5 messages, the count is going to be 5, right. Then, 2 mins later, you get 2 more, the number will still be 5. That's what TB2 did; so when I hear people being nostalgic for it, or saying it is the "expected behaviour," I can't say I agree. > Do you mean that if you did get 5, and then, before reading them, you get > another 2, it would not update it to 7 ? If this is what you mean, I agree it > might be seen as a bug. I think everyone will agree that it is even better if > it shows 7 in that situation. I don't think it was a very bad and dangerous bug > though, because in the end, what is important is that it tells us that we have > new messages, whatever the count is. This patch does what you describe (i.e., 5 + 2), and I think it moves in the right direction. What we had in TB2 was broken. What we have now is what most people (those in this bug notwithstanding) expect the count to be (i.e., Unread), and this patch does a better job of counting New. I'm just pointing out that this still won't satisfy people who thought TB2 was good, as this is something new again. IMHO extensions solve the problem of everyone wanting something different.
As someone who thought TB2 was good, I'll go ahead and say that this "fix" of showing the correct 5 + 2 count would be great. Most of us just want a badge, correct number or not is less important, to show us that there is unseen brand-new mail.
I agree with Chad. I think that this will satisfy people who thought TB2 was good. I think the major point is not the count of emails. It is the fact that it shows that you have unread emails instead of new emails. The count, being correct or not, is almost irrelevent and at best a bonus.
Though I said it earlier, I agree with Chad and Maxime. The visual indicator that new mail has arrived is the critical feature for me. The TB2 'new' count never seemed reliable and the TB3 'unread' count isn't either (I have 100 marked as unread, badge shows 95. Other times TB3 badge shows 2x the actual unread), so the count and color are irrelevant for me.
(In reply to comment #53) > (From update of attachment 419891 [details] [diff] [review]) > Thanks for the patch, it's looking pretty close. A few issues with it, then > some general comments to follow. [snip] > My final comment on this patch, and following from what I've just said, is that > I really think this should be an extension vs. something we do in tree. We > have a hook already to make this possible (i.e., you can add an observer for > "before-unread-count-display" and set the count to whatever you want). I'll > let Standard8, or whoever you use for SR, make a decision. If this *is* made into an extension, may I ask that it be compatible with SeaMonkey 2?
Humph, many thanks for reviewing my code. I fixed all of the whitespace issues and tried incorporating in your two suggestions. I've run into a couple of minor issues. If I move the code for reading the preference to ::Init, I had to put in an extra: NS_ENSURE_SUCCESS(rv, rv); after rv = prefBranch->GetBoolPref("mail.biff.use_new_count", &mUseNewCount); otherwise it fails out and the preference does not get set. The problem now is that mUseNewCount is delayed in being set. The Unread count briefly flashes on the badge, because it is not being set in time. If I move the code to "mail-startup-done" then it works as expected. I also want to point out that the way the patch is written now, you can change back and forth between new count and unread count. The InitUnreadCount() does get called because of the mDoneInitialCount flag that is checked in OnItemIntPropertyChanged(). The badge count is not updated immediately though, only when a new email comes in or something triggers the OnItemIntPropertyChanged() such as a message being read. What are your thoughts? My vote would be to just keep doing the preference checking on Badging because it works well enough and allows the possibility to change preferences without a restart, not to mention the problems with putting the code in ::Init. I'm happy to do whatever you guys think is best though. I'm a newbie Thunderbird developer!
Can you please post an updated patch with your changes as noted above, and I'll review it for you. What you describe sounds good to me.
Great, here's the patch with the whitespace hopefully all correct now!
Attachment #419891 - Attachment is obsolete: true
Attachment #425005 - Flags: superreview?(bugzilla)
Attachment #425005 - Flags: review?(david.humphrey)
Attachment #419891 - Flags: superreview?(bugzilla)
blocking-thunderbird3.1: --- → needed
Flags: blocking-thunderbird3.1+
Comment on attachment 425005 [details] [diff] [review] If a hidden preference is set, the dock icon will show the new count instead of the unread count You wrote: "The Unread count briefly flashes on the badge, because it is not being set in time. If I move the code to "mail-startup-done" then it works as expected." This is my issue. I want you to get your check in before this happens, check the pref, and we shouldn't badge with unread if the user has new set. Please fix for this, and update this patch. It's looking good, and you're on the right track. Just ironing out this startup case and I think you're good. Great work.
Attachment #425005 - Flags: review?(david.humphrey) → review-
Targetting at beta2, because we're going to need UI with strings for this, and beta2 is currently planned to be string/feature freeze.
blocking-thunderbird3.1: needed → beta2+
Attached image dock options —
The current UI I have in mind for this is to create a button in the preferencs for ( Dock Options ) which would open a dialog for change this pref. We need a separate dialog to have room to explain "new" vs. "unread" but also we could possibly further expand the dialog later to choose which folders are reported. But this attachment is a quick mockup of another way we could implement getting to the dock options dialog. I have no clue if we can easily get access to these menu items... humph do you know?
Here's the mockup of the preferences window. I've removed the Animate pref because that is moved into the dialog with the other preferences.
Humph, I don't understand. The current patch never shows the unread count if the new preference is set. This was only a problem when I moved the preference checking to ::Init from BadgeDockIcon(). I reverted the code back to the way it was, and it works perfectly. Either the unread count or the new count is displayed, depending on the preference. There is no brief flash or anything.
Attachment #425005 - Flags: review- → review?(david.humphrey)
Whiteboard: [UXprio]
the previous functionality of the dock icon needs to be restored, and it needs to be the default in thunderbird 3, not some hidden preference or extension! almost everyone (except Chad!) is talking about whether to show the count of "new" messages vs. the count of "unread" messages, but failing to realize what the dock icon is really all about: just by its presence or absence, it's the "you've got mail!" indicator. 99% of thunderbird users wouldn't care much if you removed the count number altogether. but it's absolutely unbelievable that the "you've got new mail!" indicator has been removed from thunderbird 3! what's the thing about e-mail that makes peoples' hearts jump with anticipation? in the words of blogger Scott Carpenter, "That blessed little envelope icon with its siren call to drop whatever you're doing at the moment and read your email, in the hopes that this new message will finally change your life for the better, perhaps with a promise of millions of dollars from some third world country." the "you've got mail!" notifier! hell, they even named a movie after it! with tom hanks! and meg ryan! windows users have one in their system tray. linux users have one, because they missed it so much they had to make an addon. mac users used to have one until… some guy named Dan Mills talked you into getting rid of it? wtf?? if you're going to change what the dock icon number indicates, well, whatever. nobody really cares. but you need to find some way to decouple that from the new mail notification. because believe me, *everyone* wants to know when they've got new mail! but only a relatively miniscule number give a damn whether the number shows them "new" or "unread" mail. bouncing the icon briefly, or playing a sound, is not an acceptable replacement, because it's too easy to miss if you're away from your computer. a persistent indicator in the form of a badge, colour change, or whatever, is required. as far as doing everything exactly the way apple mail does, well... that's not very "think different" of you, is it? but even apple has a preference for a persistent dock icon new mail notification - you can set it to bounce the icon, forever, until you check your mail. but who wants that? why not prove you're smarter than Steve Jobs? http://discussions.info.apple.com/message.jspa?messageID=10834071 the dock icon is for when you're working in another application. it's a way to constantly check on thunderbird's status, while you're doing something else. and the main reason to constantly check on the status, is to see if it's changed. and the only thing that's going to change when you're in another application is… "you've got new mail!". constantly checking how much old unread mail you have is pretty pointless for the majority of people, since it will never have changed since the last time you checked! ok, perhaps there are a few people who dilligently mark all their mail as "read" before switching to another application, and for them, the new design will tell them when they've got new mail. but of the millions of thunderbird users, how many do you think actually do that? i'd estimate, uh, thirty-seven. and ok, perhaps there are a few more than that who for some reason find it really important to have a constant reminder all day of exactly how much old unread mail they have. for me, it's currently 1183, which is completely useless information. but even for those people, how many of them would give up their "you've got new mail!" indicator for it? i'd estimate, uh, Dan Mills. the rest of us want our "you've got new mail!" indicator back! and we want it as the default, and we don't want to have to edit some hidden config preference or install an extension. please? p.s., for that handful of people who really do insist on seeing their unread mail count, keeping in mind that having "new" mail is a superset of having "unread" mail, how about setting a preference for a tri-state indicator: when you've got new mail, the badge is green and shows the count of new mail like before. when you've got unread mail but no new mail, it's red and shows you the count of unread mail like now. when you have neither, it goes away.
@Jeff, jeeze. Calm down man. This is an open source project. Very few people actually get paid to do this. It's mostly volunteer and grant money. There's no reason for a 12 paragraph rant. If you'd look at the bug so far, most people involved are planning on adding the functionality back in. It may not be ideal for you if it's not the default, but then write your own extension or write a patch and attach it.
I don't blame Jeff at all for his "rant". I was just as upset when I downloaded Thunderbird 3 and my new email indicator was gone! Upset enough to figure out how to become a thunderbird developer and fix it myself! ;-) At the moment I don't really care how long this gets dragged out because I can just apply the patch I made and I have the functionality back. However I'm sure everyone else wants it too, and for their sake, I hope it gets incorporated soon.
Indeed we are eager to get this, and I can promise you that I'm not gonna use TB3 until this gets incorporated in it.
so... when is this patch coming on the market ? can't wait to use TB3!
Comment on attachment 425005 [details] [diff] [review] If a hidden preference is set, the dock icon will show the new count instead of the unread count I think I'm going to step out of this bug and let someone else look at the patch. This isn't how I want to spend my free time. Patrick, what I've seen looks good thus far, keep hacking on this and other stuff in Thunderbird. Good luck.
Attachment #425005 - Flags: review?(david.humphrey)
I am very aware that behavioral changes in software can be frustrating and upsetting, and indeed, I am sometimes frustrated by such things even in code that I myself write (such as the message header changes, to name a recent example). There are many ways to deal with these sorts of feelings. Venting (such as in comment 69) is one; it's very human, and it's not terribly unusual. That said, it is not acceptable Bugzilla behavior, for the reason that you've just seen: it's _extremely_ demotivating to people who are trying to make the situation better, and it often results in the fix to the problem taking even longer than it otherwise would because volunteer developers generally don't enjoy the abuse. Jeff, please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> for more details about what sorts of things are and are not acceptable in Bugzilla. Maxime, for Thunderbird, Bugzilla is specifically used for developers and QA contributors to work directly on fixing bugs. Comments 72 and 73 are better suited for <http://getsatisfaction.com/mozilla_messaging/products/mozilla_thunderbird>. This is touched on in <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> as well.
I am sorry if I offended anyone with my comment. I was just following this bug, and it seems that the patch is ready and just need an "ok". I was just wondering what is holding it and if there was a planned date/version for it, since the lambda user can not apply this patch (I would otherwise). I can very well hold to TB2, as I have been doing, for longer. I didn't want to pressure, merely just get an idea of when it's coming.
i'd like to clarify my comment 69. i'm surprised to hear it characterized as "ranting", "venting", or abusive. i thought it was mostly humorous, but also with a well-reasoned argument about why keeping the current behaviour as the default is almost certainly not the right thing to do. although writing patches is not in my skill set, for several years now i've been making what small contributions i can to mozilla projects - mostly firefox - helping out with reporting, analysing, and testing bugs and interface behaviour. i've also volunteered literally thousands of hours of my time on other projects, and i know what it's like to feel unappreciated sometimes. but being a volunteer doesn't mean you shouldn't take pride in doing a good job, and sometimes that means accepting criticism, admitting you've made a mistake, and being willing to stick with it and fix it, even if that means throwing away a lot of work and starting all over again. in trying to make the number on the dock icon reflect something meaningful, David broke a much more important part of the user interface: the green dot indicating newly-arrived mail. the vast majority of the million or so mac thunderbird users out there, who do not follow a GTD-style regime of inbox-clearing, now have instead a red dot that just sits there permanently, indicating nothing. i guarantee that they really do *not* want that change, and the evidence of that is now coming in loud and clear. i did word my comment somewhat sharply, because it seemed like everyone else was being overly polite and saying "oh, couldn't we pretty-please set a hidden preference to get it back?". but again it was mainly intended as tongue-in-cheek humour to try to get the point across, not angry venting. i'm sorry if it came across that way. David, if you're still listening, i want to be clear that i never meant to criticize you personally, or your skills as a programmer. i think you made an honest mistake, one that anyone might have made under the circumstances. i read all the comments in the bug and it all seemed quite reasonable and rational each step of the way. several other smart and knowledgeable people reviewed it, but somehow nobody ever quite realized the larger implications of the fix. hindsight is 20/20. now, thanks to your work, and to patrick's, it seems like we'll have solutions for both the original bug, and for those people who want to use a GTD style. that's great. i personally appreciate and thank you for your contributions and efforts on this. and i hope that nothing i've said will discourage you from continuing to make them in the future.
Hi Patrick, I've tried out your patch on my own build. There seems to be one odd behaviour with it, if I manually mark a message as Unread the count increases. Is this what it is suppose to do? Also, previously in 2.0 the count would include new messages not already downloaded from the mail server. I guess maybe this can't be done with what's available now.
I'm glad to see you've tried my patch! I appreciate the feedback. Right now the way it works is whenever the unread count changes, it takes this difference and puts it in the new count, as long as the difference is positive. That's why you're seeing this odd behavior when you mark messages as unread. When I have some time I'll see if there's an easy way that I can get access to just new emails, and not have to rely on the change in unread count. I'll also see if there's some sort of event I can tap into for new mail on the server.
Glad to see its moving along. I will find some time this week to build Thunderbird with your patch and check it out. I have been following the bug list for a while, but something is wrong with my dev environment right now on this machine and I haven't been able to get a clean compile working. Plenty of material else where on that though so I'll report back when I have made some progress.
Ok, this patch should fix the marking as unread issue. I no longer rely on the difference in unread counts. Now I count only real, new email. I'm not sure if this will display the new messages that are on the server but haven't yet been downloaded..I don't have a pop account to test with. If you want to test that RP (or Iggy), that would be great!
Attachment #425005 - Attachment is obsolete: true
Attachment #425005 - Flags: superreview?(bugzilla)
Hi again Patrick, I've tested the new patch, no problems with the manual marking of messages and it does appear to count new messages still on the server. Everything seems all good so far. RPM.
Jeff and Maxime; no worries. ASCII text is a really difficult to medium to interpret tone from. Patrick, thanks so much for continuing to drive this forward. From what I can see, the things that remain to be done are: design: * mock up the "dock preferences" dialog itself engineering: * find an answer for the question in comment 66 (Patrick, is that something you know or could easily find out?) * write automated tests for both possible settings of the preference. In an ideal world, it would be possible to figure out the number in the dock from JavaScript so that one could write a functional test in MozMill; it's worth a quick look to see if that's true. My guess is that it's going to be more practical to just settle for a few XPCshell or C++ unit tests. * write code and tests for the preference UI changes Since this needs strings, it's going to need to be coded up, reviewed, and landed in the tree by string/feature freeze, which is not too far off. One of the consequences of this is that I think we should heavily bias towards whatever solution we think is going to be easiest to get coded and landed. Clarkbw, can you take a run at the remaining sub-dialog mockup? Also, are there (or should there be) analogous bugs for Windows & Linux? Patrick, are you likely to have time to continue to drive this bug forward in the immediate future? If so, it would be extremely helpful if you could look at the rest of the engineering pieces in more detail and offer some sort of guesstimate of when you might get through them. If not, I'd very much like to learn this sooner rather than later so that I can look for alternative ways to have this bug make 3.1.
OK, after some discussion with clarkbw, we decided that the right thing to block here is merely the existence of a hidden pref (i.e. the patch that Patrick has already written, modulo possible automated tests). Given that we don't have fake IMAP/POP servers for MozMill, I think my previous comment about this being testable in MozMill at all was probably wrong, but it should still be straightforward to code up some tests using XPCShell or C++. Standard8/bienvenu, can you confirm or deny? Patrick, I'm still interested in your thoughts about whether you're likely to have time to drive this forward in the very near future or whether I should be looking to find someone else get this to the point of landing in the tree.
Hey, sorry for the delay in responding. Unfortunately I've been really busy lately with work and I no longer have much free time. If it's not too hard to find someone else to do the things you mentioned, that would be great. Otherwise, I might have time this weekend to work on it.
No worries re the delay. This weekend would be fine. If you don't get a chance, I'll see what I can figure out next week. Thanks!
Patrick, is it likely that you'll be able to finish up work on this bug in the next day or two? If not, I can take a run at this starting on Thursday...
Hey Dan, I think it might be better if you took a look at it. Unfortunately right now there's too much going on, and learning about how all the testing works and some of the other things you mentioned is just a bit too much right now. Simple bug fixes I can do if there are problems.
No worries, and thanks for writing the patch!
Assignee: accounts → dmose
Whiteboard: [UXprio] → [UXprio] [has patch, needs test, review]
Hey guys, I have been reading the entire thread a couple of times but I am unsure about how you intend to fix it. 1) will you restore the old functionality (dock icon showing the new messages)? or 2) fix the issue by which unread messages count is broken as it does not consider the unread emails moved to other folders by the filters? Also, if you opted for 1) are you checking whether the patch does not suffer of the same issue for which filtered emails are not accounted? I personally find this part quite more annoying than the fact the icon shows new emails as opposed as unread ones. RS
Hi Ricardo, This patch allows you to set a preference for showing new mail instead of unreal mail. All new mail, regardless of filters is part of the new mail count. It doesn't change any of the behavior for the unread email count. It's not a rollback of the original code..the code is new and doesn't suffer from some of the drawbacks before, like showing the wrong number of new messages, which it was often prone to do. Patrick
Hi Patrick, ok thanks for the clarification ;) RS
Count me as someone who's going back to Thunderbird 2. Having a dock icon display the number of unread messages is utterly useless for me. Open source or not, it's a poor showing to spring such an objectionable change upon the users. In fact, I'd say it's a pretty poor showing to take the better part of a year of dragging your feet to come up with a fix. Given how late in the game this change was made, and how negative most of the feedback has been, perhaps it would have been better to simply revert it until a proper fix can be committed? If the Windows and Linux builds of Thunderbird 3 still have a proper new messages indicator, why on earth wouldn't the Mac builds have one?
I'm just adding a "me too" in the "I went back to tbird 2" camp. The current tbird 3 method is a show stopper for me.
I think the only thing that needs to be done is test the patch that I made. I am not familiar with writing these tests and no longer have time to read a bunch of mozilla docs on the correct procedure to do this. Can someone who has done this before write up a couple of tests and get my patch into one of the next thunderbird releases? I am also looking forward to the point where I no longer have to open "Shredder" to check my mail. :-)
After spending a bit of time looking at the code here, I've come around to the point of view expressed by bienvenu in a meeting a while back, which is that the cost of writing a test is likely to be significantly higher than benefit. The code looks fine, but I need to do a bit of manual testing before I stamp r+ and mark needs-checkin. That will happen soon.
Here's an updated patch; I've added the pref to mailnews.js so that it's visible in about:config, and I've updated the name of the pref to be more explicit that it only effects Mac. Thanks for both the patch and your patience with the review turnaround, Patrick!
Attachment #429856 - Attachment is obsolete: true
Attachment #439399 - Flags: review+
Keywords: checkin-needed
Whiteboard: [UXprio] [has patch, needs test, review] → [UXprio] [has patch, needs landing]
Wonderful, thanks a lot Dan!
Pushed: <http://hg.mozilla.org/comm-central/rev/841cb1484bcd> changeset: 5450:841cb1484bcd tag: tip user: Patrick Nagurny <accounts> date: Tue Mar 02 15:22:00 2010 -0800 summary: Bug 518828 - "Need a new preference to allow "New Mail" count for dock icon instead of unread mail count" r=dmose
Assignee: dmose → accounts
Status: NEW → RESOLVED
Closed: 15 years ago → 15 years ago
status-thunderbird3.1: --- → beta2-fixed
Resolution: --- → FIXED
If folks are interested in moving forward the mockups Bryan did earlier on, please file a new bug. Adding relnote keyword because some Tb2 users are going to want to tweak this pref after we upgrade, since the default behavior has changed.
Keywords: checkin-needed → relnote
Whiteboard: [UXprio] [has patch, needs landing] → [UXprio]
Are you saying that the default setting will still be to show an "unread mail" notifier rather than a "new mail" notifier for Mac users? Please excuse me if I have that wrong... I still really think the default behaviour should not change from Tb2, and should be consistent with the Windows Tb2/Tb3 version. If the default behaviour changes, not just some but virtually *all* Tb2 users are going to want to tweak this pref when they upgrade. Why not set it that way by default, and avoid the hassle for millions of people? Do you agree, Patrick? This bug is ostensibly about whether Mac users see a count of new mail or a count of unread mail. But in fact, it's about whether they receive a notification or alarm on new mail arrival events - or they don't. As I said previously, practically all people want to be notified when new mail arrives, via a "biff" type of "indicator light" or alarm coming on in the dock or system tray. Almost nobody wants to have to always mark all their mail as read, every time they interact with Thunderbird, in order to achieve this - to "arm" the alarm. Whether the notifier alarm has a number associated with it, and what that number means, is relatively unimportant compared to the main function of the "indicator light" as a notifier of new mail arrival events. Also, the Mac's dock notifier should, by default, remain consistent with Windows' system tray notifier. The only difference in Windows is you have to hover the mouse over it to see the number, instead of having it embedded in the dock/tray icon. Apparently the number was inaccurate in the Mac version (although it seems to me to be just as broken on Windows?) but that has been fixed now by Patrick's patch. I just can't see any logical reason to remove the dock/tray new mail event notifier, and replace it with something else, as the new default behaviour, only in the Mac version. The idea that most Mac users want an "unread mail" readout, while Windows users want a "new mail" event notifier, simply makes no sense. That's backed up by all the feedback on this bug, which will continue even if there's an entry in the release notes pointing to a hidden preference, because many people just won't find that. Is it possible to have the default setting of the pref set to show a "new mail" notifier when it's released? Thanks...
Going to back up Jeff on this. I failed to post proper testing on the patch earlier, because I still can't get a clean compile of Thunderbird, but that issue is another issue all together outside of the scope of this bug. Given the vast amount of complaints I would expect this patch to revert the behavior and allow the new option to give users the opportunity to change the behavior to the new feature of Thunderbird 3.0.
I do agree with both of you, that it would be a lot better for the default option to be Thunderbird 2's behavior, because that is what everyone is used to and expects. And for most people, a new mail indicator is infinitely more useful than a GTD unread indicator. However, at the moment, I'm just glad that we have the ability to revert it back! I guess this is just a political battle now..between people of the mind of bug 274688 and this bug. Based on volume and intensity of user comments, it does seem like having it show the new mail is more important to a lot of people. The actual code to change the default, added by Dan, is extremely basic and easy to change: -------------------------------------------------------- // If true, the number used in the Mac OS X dock notification will be the // the number of "new" messages, as per the classic Thunderbird definition. // Defaults to false, which notifies about the number of unread messages. pref("mail.biff.use_new_count_in_mac_dock", false); --------------------------------------------------------- That's my 2 cents. Personally, I will be happy to use Thunderbird 3 now with a new mail indicator, even if it's a hidden preference to be set.
Patrick: to force the issue, you could submit the patch, and request blocking of tb 3.1 on it. That usually at least forces a decision (don't tell the drivers I recommended that, by the way!). Otherwise it gets lost. New bug, by the way.
There is quite literally _no_ default here that will make everyone happy. I get that some people believe that we've chosen a default that will not work well for the majority of users. We disagree. The reality is, there are a bunch of different ways to use email, and this bug has selected for commenters whose mode of use is incompatible with the new default. The decision has already been made, there's nothing to force. I apologize if we weren't sufficiently clear about it earlier.
As much as I wish that the preference didn't change in 3.0, it already did. It would be annoying to change default behavior again. It only changed in 3.0 because the old behavior was absent. That's not the case in 3.1
I've been following this bug for awhile, and am happy with dmose's code and the ability to change the behavior, but for the life of me cannot figure out how to actually change it in the UI. I am using Thunderbird Mac 3.1.2. Is this for a future version (3.2)?
@Brad > Thunderbird>Preference>Advanced>General>Config Editor type: mail.biff.use_new_count_in_mac_dock change to true
Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you!
This got into 3.1.x which has been out a while now. So I don't think its worth the effort of backporting into 3.0.x.
blocking-thunderbird3.0: needed → ---
Thanks Sumit, works great, though are there plans for adding this to the GUI for use by non-technical user? Keep up the great work!
I also prefer thunderbird showing "new mails" instead of "unread mails". So I'm very glad there is an option to go back to the old behavior. But there is a main difference in how thunderbird is counting new mails. E.g. if thunderbird is checking for new mails every 10 minutes and 1 email is arriving, in thunderbird 2 the counter stays at 1, regardlessly how often thunderbird will check for new mails. But in thunderbird 3 with the code from Patrick(?) thunderbird will add 1 more new mail every time it is checking for new mails. So e.g. after 60 minutes checking every 10 minutes for new mails, thunderbird will show 6 new mails, but actual there is only 1 new mail.
Hi Michael, are you experiencing this problem using a POP server? Does anyone else have this problem?
Yes, I'm using a pop-server.
I've seen this problem occur a few times, also using a pop3 server. It only seems to happen if Thunderbird is left alone and you don't select the particular account in the list.
Given that this code itself is in the tree and this bug is resolved, please file any new problems with the code as separate bugs. Thanks!
I still haven't got a straight answer - Is there a GUI (non-config) way to set the behavior as new or is there one being worked on? As it is, I would barely classify this issue as fixed from an accessibility standpoint. I see this as the biggest thing that would get TB2 holdouts to switch...
No, there's no GUI way to set this, and I don't know if anyone is working on one.
I'm also running Thunderbird 3.l.5 on a Mac (under OS 10.4.11, downloading from an AT&T/Yahoo POP server) -- with Preferences reset to reflect the so-called "fix." It's doing exactly the same thing as it is for Michael K: every time it checks the server, it adds the full number of as-yet-undownloaded messages and adds that to the total count thus fare -- and keeps doing this, cumulatively, every time it comes around and checks. (I believe I have it set to check at ten-minute intervals, so it's not unusual for that little green number to mount up to a hundred over the course of an hour, or 1,000 if I leave the computer running overnight,) With version 2, I always had an eye out for that number, off in the corner while I'm working on something else, or when I first wander past my desk in the morning: very handy for gauging and planning time allocation on-the-fly. Oh, and did I mention another slight problem, maybe (or maybe not) related?: I have T'bird set to play a sound ("Quack!") the first time there's a new message on an empty server. (I may even have it set for the icon to bounce once or twice in the dock. Despite the setting, in Version 3 it doesn't work: no "Quack," no bounce. This IS a big deal; it affects the entire "look and feel" of the UI, the fundamental experience of using the application. Hey, wasn't there even a movie a few years back called "You've Got Mail"? It still needs to be fixed!
I'm also running Thunderbird 3.l.5 on a Mac (under OS 10.4.11, downloading from an AT&T/Yahoo POP server) -- with Preferences reset to reflect the so-called "fix." It's doing exactly the same thing as it is for Michael K: every time it checks the server, it adds the full number of as-yet-undownloaded messages and adds that to the total count thus fare -- and keeps doing this, cumulatively, every time it comes around and checks. (I believe I have it set to check at ten-minute intervals, so it's not unusual for that little green number to mount up to a hundred over the course of an hour, or 1,000 if I leave the computer running overnight,) With version 2, I always had an eye out for that number, off in the corner while I'm working on something else, or when I first wander past my desk in the morning: very handy for gauging and planning time allocation on-the-fly. Oh, and did I mention another slight problem, maybe (or maybe not) related?: I have T'bird set to play a sound ("Quack!") the first time there's a new message on an empty server. (I may even have it set for the icon to bounce once or twice in the dock. Despite the setting, in Version 3 it doesn't work: no "Quack," no bounce. This IS a big deal; it affects the entire "look and feel" of the UI, the fundamental experience of using the application. Hey, wasn't there even a movie a few years back called "You've Got Mail"? It still needs to be fixed!
@ Mitch in Oakland. As said in comment 117. A new bug will have to be filed for the pop server new mail adding up. I was going to get round to it but I've been really busy lately and haven't had time to file one. As for the sound problem, try selecting another sound, restart Thunderbird and reset the sound back to the "Quack" you originally had. Give that a go, see if it fixes it.
I am running Thunderbird 3.1.9. Just upgraded from 2.0.0.24. Max OS X 10.5.8. I don't see any "Dock Options" Preference. Why is this not visible?
(In reply to comment #124) > I am running Thunderbird 3.1.9. Just upgraded from 2.0.0.24. Max OS X 10.5.8. > I don't see any "Dock Options" Preference. Why is this not visible? Please read [url=https://bugzilla.mozilla.org/show_bug.cgi?id=518828#c109]comment 109[/url] on how to set this.
Oops, sorry, forgot how to use links here. It should say: Please read comment 109 on how to set this.
(In reply to comments #123 & 125) > As said in comment #117, a new bug will have to be filed for the pop server new mail adding up. > > As for the sound problem, try another sound, restart TB, then reset it back... Thanks, "R P Mozley" (as new activity here jogs my memory)! The POP server new message count remains a problem, and evidently a new bug was never filed. The number displayed in the dock keeps increasing each time TB checks the server for new messages (at whatever interval it's set to check automatically), even if no new messages have arrived since the last time the server was checked. Each time TB checks the server for new messages, it apparently counts the entire number of messages it finds there. It then adds that number to the existing number of messages it had found (and thus, had already counted) the last time it checked, and the number in the dock is updated to reflect the total. In other words, each time TB checks for new messages on the server, it counts all the messages that have arrived since the last download -- and then nonetheless adds this number onto the pre-existing count it generated the last time it had checked (a number included in the new count, that's thereby being counted twice) to get a new cumulative running total-- and it does this recursively, each time it checks automatically for new messages until a download is performed, so the total can rather quickly get quite large. I perform the downloads manually, and I've noticed that the moment I click on the "Get Mail" button to do so, the number in the Dock changes to reflect the true total of new messages, often apparently even before I'm logged onto the server or before the download has, in fact, begun. Wouldn't it be possible for TB to perform this "zeroing-out" function each time it does an automatic check, before updating the number in the Dock?
Keywords: relnote
(In reply to R P Mozley from comment #123) > @ Mitch in Oakland. > > As said in comment 117. A new bug will have to be filed for the pop server > new mail adding up. I was going to get round to it but I've been really busy > lately and haven't had time to file one. I just stumbled onto this old item, which refers to a problem that persists (all the way to TB 38.0 beta!). Was that new bug ever filed? I've been living with the problem for years, but it's annoying! This is the case despite the fact that the config editor is set as: type: mail.biff.use_new_count_in_mac_dock - "true" One hint of a possible reason for this problem is that, as you've noted, "It only seems to happen if Thunderbird is left alone and you don't select the particular account in the list." I've been using TB for over a decade, and my current configuration remains as it was when migrated from Netscape Mail! My mail downloads (and deletes) from the POP server directly into the "Local Mail" global inbox. "Local Mail" is designated as a "special account not associated with any identities," and (in addition to that global inbox) that account also includes an array of folders into which I move and manually archive incoming mail as I read it. If this is the source of the problem, is there a way to change my account settings to fix it - without losing (or losing track of) that accumulated content?
Flags: needinfo?(accounts)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: