Closed Bug 123104 Opened 23 years ago Closed 22 years ago

Mail Notification tooltip shows the wrong count

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: scottputterman, Assigned: mscott)

References

Details

(Whiteboard: [ADT2])

Attachments

(2 files, 1 obsolete file)

Screenshot (sorry about the trial version text)
50.03 KB, image/gif
Details
fix for the problem reported in this bug
947 bytes, patch
Bienvenu
: review+
sspitzer
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
Using the 1/30/01 build on Win 2000 with an IMAP account, the new mail
notification tooltip in the Windows system tray reports the wrong count for new
mail.

I'm currently in a state where no matter how many new messages I receive or
read, the tooltip always says "scottip has 10 new messages".  For example, If I
send myself two new messages, it says this and if I read those messages it says
this.

I've had this session running for at least 9 hours so I don't know when the
count started going bad.
I opened every folder and subfolder on my IMAP account just in case there was
some new message I was missing due to filters.  Doing this should have cleared
any new flags if they existed (I had previously looked in all folders that had
the new icon on them).  After doing this, the tooltip still showed that I had 10
new messages.
duplicate of bug 122293?
QA Contact: esther → sheelar
I don't think so for a couple of reasons.

1.  The build I'm using now should have that fix and I still see the problem.
2.  That bug seemed to be about reporting 0 new messages and I'm seeing a number
that's too high.
The message count did show the correct message count when you get messages
manually by Get message button using today's build(2002-02-04-06 on WinNT)
However, when biff goes off and fetches the new message it does show the wrong
count of messages in system tray icon in the tooltip.  
I think I see the problem.
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.9
Attached patch the fix (obsolete) — — Splinter Review 
This should fix the problem but I need play with it more.
Currently we set the # of new messages for a folder when we select the folder
and we download new headers for it. Currently no one ever sets this number back
to 0. It would only change if you reselected (or biff went off) the folder and
had to download more new headers for the folder. Otherwise, the new message
count for a folder would not change. This lead to the accounting discrepencies
we are seeing. 

The fix is in nsMsgFolder::SetBiffState. If we are setting the state of a folder
to "no more new mail", then at the same time, we'll clear the num new messages
count for the folder.
Status: NEW → ASSIGNED
Comment on attachment 68453 [details] [diff] [review]
the fix

r=naving
Attachment #68453 - Flags: review+
Comment on attachment 68453 [details] [diff] [review]
the fix

sr=bienvenu
Attachment #68453 - Flags: superreview+
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 125337 has been marked as a duplicate of this bug. ***
Question for either Scott,

I'm trying to verify this for Sheela. I assume this is a windows
only feature. my question is I notice this behavior which
leads me to believe this problem isn't fixed?

Using commercial trunk 2002030103 on NT 4.0

Situation:
 1.I login to my imap mail act
 2.Make sure no unread mesgs
 3.Set my pref to check mail every 1 minute.
 4.Send a mesg to my mail acount
 5.I hear the beep and see the new mail icon in system tray.
 6.I move my mouse over it and tooltip shows: <username> has 1 new mesg
 7.I don't click on the new mesg, (i just have the folder selected
   and not a particular mesg)
 8.I send myself another mesg
 9.Wait until the new mesg appears
 result: when I move the mouse over system tray icon, it still
         shows I have only 1 mesg instead of 2.

This behavior is the same for imap & webmail acnts. I see some
strange behavior in pop but need to find out if there are bugs
on this already.



adding myself to cc list
QA Contact: sheelar → stephend
I'm reopening, just for consideration/fleshing out - don't we want to have a
listener on that task tray that gets notified when the new count rises in the
Inbox?  Sorry all, I'm still reading the spec as I go.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I see the same thing.  I send myself a mail and the tooltip says there are 6 new
messages (as far as I can tell, that number is right).  I send myself another
mail without ever touching my Inbox or doing Get Msg and when biff goes off, the
new mail arrives and the tooltip still says that there are 6 new messages.  All
of the "new" messages I hadn't read still have the "new" status in the thread pane.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla0.9.9 → mozilla1.0
Discussed in Mail News bug mtg with Engineering QA Mktng PjM.  Decided to ADT3
this bug.
Whiteboard: [ADT3]
Discussed in Mail News bug mtg with Engineering QA Mktng PjM.  Decided to ADT3
this bug. 
removing stephen & adding myself as qa. there has
been reassignment in qa duties.
QA Contact: stephend → gchan
I believe the problem has to do with filters & imap. When an imap filter fires
and moves a message away from the inbox, we start getting confused about the
total new mail count. In particular, after you read the message in the filtered
folder, internally we still think you have "1" unread message (probably pointing
back to when it used to be in the inbox). From this point forward we'll always
be off by 1  message in the tooltip counts. The next time this happens we add
another extra count and so forth.  
I don't use filters, so that doesn't cover my case ;-)
This bug is now tracking two separate issues.

1) The original issue is that the message count gets thrown off. When using
filters, it's possible to get in a state where it says you have more unread
messages than you really do. 

2) stephend made a feature request in this bug, asking the tooltip count to be
dynamically updated as more mail comes in during multiple biff intervals where
you aren't reading any of the original new messages. 

I just wanted to clarify this before I start posting patches for these 2
different issues. 
This patch fixes the original problem as reported in the bug. We only reset a
folder's new messages count if the server's biff state was different than the
current biff state. This breaks down when you have new mail in multiple folders
and we end up changing the biff state to no mail when you read them in the
first folder (thereby resetting the count for that first folder). Later on if
you read messages in the 2nd folder, we won't end up clearing the count for
this folder because we are in synch with the server biff state.
Attachment #68453 - Attachment is obsolete: true
Raising the impact.  A lot of users will see the notification alert.
Whiteboard: [ADT3] → [ADT2]
I'll be happy to run with this patch, since I'd love to see this fixed. When I
see that it works, I'll stamp r or sr, whichever you want.
Hey David, actually this patch is partially incomplete. It may fix the problem,
but it may also require an additional change. One big reason why the counts get
out of synch has to do with incoming imap messages and filters. 

In nsImapMoveCoalescer::PlaybackMoves, we move messages from your inbox to
another folder (assuming a filter fired that said to do that). In that routine
we do the following:

        destFolder->SetNumNewMessages(keysToAdd->GetSize());
        destFolder->SetHasNewMessages(PR_TRUE);

But we never decrement the # of new messages in the source folder. I suspect
we'll need to do that too.

I doubt I get back to working on bugs until next Thursday so if you want to run
with this before then go for it =).


ok, taking for now.
Assignee: mscott → bienvenu
Status: REOPENED → NEW
back to mscott - he thinks this is sufficient to fix this bug, but I'll drive
getting this checked in.
Assignee: bienvenu → mscott
I believe mscott's comment about filters is correct, and needs to be addressed
for this to be fixed as well. I'm not sure what the intent is here - if I get 5
new messages, and filter t3 of them to another folder, the alert should say "5
new messages". If I read the 2 new messages in my inbox, and then another new
message arrives, should we say there are 4 new messages (the 2 new ones and the
2 filtered messages that I haven't read), or just 2 new messages? The latter, I
believe, since it's really not feasible for us to figure out if you've read
filtered imap messages. I've run with the existing patch, and I don't think it
accounts for filtered messages correctly yet.
Comment on attachment 76270 [details] [diff] [review]
fix for the problem reported in this bug

r=bienvenu - this seems to work for me in my testing so far.
Attachment #76270 - Flags: review+
I think the answer to my question is that we show the number of messages that
*just* arrived and that seems to work. I get a lot of filtered mail, and it's
hard to remember how many messages just came in, so I was getting a bit
confused, but it seems to be working consistently.
Comment on attachment 76270 [details] [diff] [review]
fix for the problem reported in this bug

sr=sspitzer
Attachment #76270 - Flags: superreview+
actually, by design, we show you the total number of "new" messages in each
folder, so you actually have to go open each folder that has messages filtered
into it to get the count to go down. That's not really the way I would want it
to behave - I would just like to know the number of new messages that just
arrived in my inbox, independent of whether they were filtered to other folders
or not...but this bug is not about that, I guess.
This has been checked into the. Leaving open until I get it into the moz 1.0 branch.
nominating for adt1.0.0
Keywords: adt1.0.0
Pls Note: You can mark this one as Resolved/Fixed once it hits the trunk. The
ADT looks for ALL bugs with adt1.0.0 keyword (Reolved or Open). When bugs are
fixed on the 1.0 branch, pls replace adt1.0.0+ with fixed1.0.0 keyword. After QA
has verified the fix is in the branch, pls replace fixed1.0.0, with verified1.0.0.
gary can you try this out on today's trunk build and update the bug with the
results?
This should be marked fixed since it is fixed on the trunk. Once QA has had a
chance to look at it I'll petition drivers for the branch.
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Using 2002-04-16-06-trunk NT 4.0

I tested 3 things. I think I need clarification on what this
bug fixes:

1.Comment 22:
>stephend made a feature request in this bug, asking the tooltip count to be
>dynamically updated as more mail comes in during multiple biff intervals where
>you aren't reading any of the original new messages. 

So I sent myself 1 mesg from my imap acnt. Waited for biff to go
off, alert, then notification icon appears. Moved my mouse over
icon, it said i have 1 new mesg. I didn't read any mesgs or click
on the folder pane. I then composed another mesg and sent it to myself.
Waited for Biff to say 2nd mesg has arrived. Moved my mouse over 
notification icon, it still says I have 1 new mesg.

Should it say 2 new mesgs?

2)tested sending like 4 new mesg to account and waiting for biff/mail
  icon to go off. The tooltip showed 4 new mesgs

 This passed.

3)I assume that this one case, this bug will not cover:
  -Send myself a mesg wait for biff/icon to go off
  -click on folder in account but don't click on the new mesg
  -notification icon goes away
  -the mesg still is new (don't click on it)
  -send another new mesg myself and wait for biff/icon to go off
  -the mail notification icon tool tip still shows 1 new mesg

  Which I assume is correct? We only care about new mesgs coming
  in. Once icon goes away, when it reappears it only tracks new 
  incoming mesgs not total new mesgs? Right?


4)Filters.
  A)Tested where I sent 3 mesgs to a filtered folder:
    The tooltip showed 3 new mesgs. Passed.
  B)Tested where I sent 2 mesgs to filtered folder and
    1 mesgs to the inbox. Tooltip showed 3 new mesgs. Passed.
  C)Tested where I sent a mesg to inbox, mesg to a filtered folder,
    another mesg to filtered folder. Result was that tool tip showed
    3 mesgs.
  D)Tested 2 mail accounts (imap/pop) Sent a filtered mesg to imap
    acnt, sent a filtered mesg to pop acnt, and sent a regular mesg to
    pop acnt. Tool tip showed the correct counts.


Reopening bug based on my 1).


Reopening bug
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
re-closing. I believe i said stephend's enchancement should be a new bug as it
has nothing to do with the bug here where the animated alert was showing in
accurate counts. 

According to your tests, we've fixed this bug as it was initially described. Let
me know if I misunderstood.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
ok mscott. I'll file a new bug w/stephen's enhancements.

need to quickly check other window os's..

verified 2002-04-16-06-trunk on 2k & NT 4.0

Tooltips are showing the right counts.

Verified on trunk.

adt1.0.0+ (on ADTs behalf) approval for checkin to 1.0 branch. Pls check this
into the 1.0 branch and trunk today. After, this has landed on the branch, pls
add the fixed1.0.0 keyword.
Keywords: adt1.0.0 → adt1.0.0+
Changing status to verified on Gary's behalf!
Status: RESOLVED → VERIFIED
Comment on attachment 76270 [details] [diff] [review]
fix for the problem reported in this bug

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #76270 - Flags: approval+
Fixed on the 1.0 branch
Keywords: adt1.0.0+ → fixed1.0.0
Using: 2002-04-20-06, with Gary's testcase involving filters with IMAP/POP, IMAP
& POP, I've verified that this is fixed on:

Windows 98, Windows NT 4.0, Windows 2000, and Windows XP.

Note that I've filed bug 138095 for the problem I mentioned in comment 14 and
Putterman reiterated in comment 16.

Verified FIXED on branch and trunk, so replacing fixed1.0.0 keyword with
verified1.0.0
Keywords: fixed1.0.0 → verified1.0.0
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: