Closed Bug 375717 Opened 15 years ago Closed 5 months ago
New mail notification (mail alert/preview text) shows old items
16.62 KB, image/png
6.37 KB, patch
|Details | Diff | Splinter Review|
1.28 KB, patch
|Details | Diff | Splinter Review|
Look into the attachment. When I get a mail into the global inbox, the new mail notification popup shows four other items and not the new one. Furthermore, these other items are stored in a subsubfolder of the global (local) account.
Basically a dupe of bug 138631.
No, the number is correct, but the window shows rss items in subsubfolders of "Local Folders" (not of the inbox).
This seems to be related to bug 377301.
I believe this is still happen for Thunderbird 3 nightly builds. Anyone tested it yet?
Status: NEW → ASSIGNED
Summary: New mail notification shows wrong items → New mail notification (mail alert/preview text) shows old items
version 3.0a1pre (2008040903) Yes, still exists. Nominating for blocking-thunderbird3.
Assignee: mscott → nobody
Status: ASSIGNED → NEW
TB thinks its new mail until you open folder where new mail comes or change to other folder if you in folder where new mail comes. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/2008072303 Shredder/3.0a2pre.
Hardware: PC → All
Version: 2.0 → Trunk
Triaging according to policy for flags. https://wiki.mozilla.org/Thunderbird:Release_Driving
Priority: -- → P2
Target Milestone: --- → Thunderbird 3.0rc1
If someone with a win32 build env could try this for me, that would be great.
David, why do we need especially someone with win32 build env?
(In reply to comment #14) > David, why do we need especially someone with win32 build env? I've fixed this on Mac (see bug 459483), and wanted to do it on Windows too. I thought this bug was Windows only, so my mistake. However, this fix touches nsMessengerWinIntegration, so Windows ;) The reason this bug occurs is that we currently cache the root folder which is getting the biff notification, and when the second/third/etc. one comes in, it uses mFoldersWithNewMail (i.e., the first folder that got biff) every time vs. the folder reporting new mail.
I tested the patch 348817, and it compiled fine, but neither from the bug nor from IRC discussions with humph was I able to reproduce the problem this bug is trying to solve without the patch applied. Some clear steps to reproduce would be very helpful.
Kent, Just get new mail - > new mail notification appears get another new mail -> new mail notification appears showing alongside with first message. You can clear counter by changing folders and come back.
(In reply to comment #17) > Kent, > Just get new mail - > new mail notification appears > get another new mail -> new mail notification appears showing alongside with > first message. > You can clear counter by changing folders and come back. This is not the problem that humph described to be he was trying to solve. So, Nikoly, I send email "showme 1", receive it, biff shows "showme 1". I send another email, "showme 2", receive it, biff now appears with both "showme 1" and "showme 2". And your desired behavior is that the second notification only shows "showme 2" - is that correct?
Exactly. Just email that arrive right now.
Nikolay, the behavior that you describe is one of the reasons for my proposals in https://wiki.mozilla.org/User:Rkentjames:NewCounts Basically, we need a new flag, described there as 'A new flag MSG_FLAG_BIFF will be defined as "This newly received message has not completed a BIFF notification cycle"' Now that bienvenu and I seem to have resolved some issues associated with the backend for such processing flags, perhaps we need to reopen the questions in that proposal. Bienvenu seems unconvinced of the need for this flag (and I will admit I am able to do more under the current model than I previously thought possible) though I should let him speak for himself (hence my shameless misrepresentation which always elicts a reaction).
Note that we have a nsMessengerUnixIntegration.cpp too
Sure, the code is the same (see bug 458507). I'll do that too, as soon as someone who reported or experiences this can tell me whether this fixes their issue on Windows.
(In reply to comment #21) > Note that we have a nsMessengerUnixIntegration.cpp too To clarify - did you mean there's a patch somewhere that fixes this for Unix or that we need a patch that also fixes it for Unix? I'm seeing such errant behavior on linux (I've got certain 'special' IMAP folders that always show their old messages in the biff list despite no UI-visible differences).
fwiw, I've fixed this (and a bunch of related bugs) already for Mac, and all the nsMessenger*Integration implementations share the same set of bugs. I'm not sure the best way to get the changes across all platforms (bug-by-bug or all at once in a new bug), but I'll look into it.
I think I'm seeing the same thing. I have a bunch of IMAP folders and there will be unread mail sitting in some of them. I expect notifications when I get new mail in INBOX, bot not the others. This seems to work fine except that the summary in the alert shows unread mail in other folders. If I restart TB, it works fine until I visit one of these other folders at which point the summary will be wrong for the rest of the session.
humph: any progress? If not, i might take a look.
Assignee: nobody → mkmelin+mozilla
I might have time for this next week, actually. Let me take a look today. What's really involved here is moving Windows toward fixing bug 458507, which will fix this and a bunch of other things. We've had this fixed on Mac for a while.
Assigning to you for now then:)
Assignee: mkmelin+mozilla → david.humphrey
dupe of Bug 226885 ?
(In reply to comment #18) > This is not the problem that humph described to be he was trying to solve. So, > Nikoly, I send email "showme 1", receive it, biff shows "showme 1". I send > another email, "showme 2", receive it, biff now appears with both "showme 1" > and "showme 2". And your desired behavior is that the second notification only > shows "showme 2" - is that correct? I just noticed that behavior was changed, you now only notified for first mail and not notification for second, etc. xref 627333 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110117 Thunderbird/3.3a3pre
So, I am new to Thunderbird, and apparently this "bug" has been going on since 2007? Does that mean that Mozilla doesn't follow up on bug reports from their customers ta all then? My new mail notification also shows more than the new email - sometimes messages that have been moved to the trash. I am using Gmail, IMAP with the latest version of Thunderbird Beta 10. It would be nice to see this fixed. K
Year 2013.... 5 years ! Come on...It might not be so important but its a very visible and kind of frustrating one.And i don't think any bug takes 5 years to fix.I know you guys are busy with a lot of others things probably I'm a programmer too i understand a bit.But 5 years for a so small bug...
Is the patch still relevant? I'm still getting this in Mountain Lion, Thunderbird 24.3.0. In the settings there is nothing for the notification window. When it pops up I get useless info. The subject line is for an unread email, but not the one that just arrived. It also tells me I have 2000 odd new messages, which is useless. I want to see the subject/from for the email that just arrived and how many unread in my inbox/unified inbox.
This has been happening to me and driving me crazy for years. Please fix!
To the developers trying to reproduce the problem: you must have multiple mailboxes configured. Although Thunderbird properly notices e-mails arriving to all of them, what the new-mail popup often lists are already-reported (but still unread) messages, instead of the one(s) that just arrived and, actually, triggered the popup in the first place. Instead it should show the very latest arrivals, obviously. Using 38.4.0 here and this is still a (very annoying) problem.
(In reply to Mikhail T. from comment #46) > To the developers trying to reproduce the problem: you must have multiple > mailboxes configured. > > Although Thunderbird properly notices e-mails arriving to all of them, what > the new-mail popup often lists are already-reported (but still unread) > messages, instead of the one(s) that just arrived and, actually, triggered > the popup in the first place. > > Instead it should show the very latest arrivals, obviously. Using 38.4.0 > here and this is still a (very annoying) problem. Me too. Multiple mailboxes configured, all are IMAP. The New Email popup occurs when a new delivery is received to any of my mailboxes but instead of showing the newest email received, it shows the first four 'unread' emails in any of my mailboxes (well, one is dominant). Every. Single. Time. So aside from being aware i've received a new message, it serves no purpose (and i'm tempted to turn the whole feature off). This has been ongoing for a long time.
The last few comments are correct. It should show the last four unread messages, not the first four.
> It should show the last four unread messages Not quite what I said. It should show _all_ of the messages, that actually triggered the new-mail notification in the first place -- even if there are other unread messages in the mailbox. For example, suppose there are 5 unread messages. Thunderbird performs its periodic check and detects 2 new ones. Only those two should be included in the notification. And it must properly handle the case, when new messages are detected in multiple accounts...
OK - but I would be happy if it showed only the new ones OR the last four unread messages - and not the first four unread messages.
(In reply to Mikhail T. from comment #49) > And it must properly handle the case, when new messages > are detected in multiple accounts... Each of my 7 accounts currently gets its own popup for notifications, so this should not be an issue.
Assignee: nobody → remotenonsense
Status: NEW → ASSIGNED
Comment on attachment 9204515 [details] [diff] [review] 375717-num-new.patch Review of attachment 9204515 [details] [diff] [review]: ----------------------------------------------------------------- ::: mail/base/content/foldersummary.js @@ +136,5 @@ > > folder.msgDatabase = null; > let msgKeys = msgDatabase.getNewList(); > > + // NOTE: getNewlist returns all unread messages, while getNumNewMessages unread != NEW. NEW is imap UNSEEN. getNewList lists NEW. Does getNumNewMessages also consider the things messages we got through IDLE?
Comment on attachment 9204732 [details] [diff] [review] 375717-num-new.patch Review of attachment 9204732 [details] [diff] [review]: ----------------------------------------------------------------- LGTM, r=mkmelin
Attachment #9204732 - Flags: review?(mkmelin+mozilla) → review+
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.