Closed Bug 336831 Opened 15 years ago Closed 15 years ago

Biff doesn't clear from system tray.

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: stephend, Assigned: mnyromyr)

References

Details

(Keywords: fixed-seamonkey1.1a, fixed1.8.1, regression)

Attachments

(1 file, 1 obsolete file)

Build ID: 2006-05-05-13 of SeaMonkey trunk under Windows XP.

Summary: Biff doesn't clear from system tray.

Likely that this is a regression from bug 133917.

Steps to Reproduce (at least on IMAP):

1. Receive a new message, and see that you get notification (via popup alert notification _and_ system tray).
2. Read message.
3. If biff still hasn't cleared, click GetMsgs.

Expected Results:

The system tray notification should disappear.

Actual Results:

System tray notification icon lingers: "stdonner@iusb.edu has 1 new message."
This might fix it, but I've not tried it:

   // okay, we are done showing the alert
   // now put an icon in the system tray, if allowed
-  PRBool showTrayIcon = !mSuppressBiffIcon;
+  PRBool showTrayIcon = PR_TRUE;
   nsresult rv;
   nsCOMPtr<nsIPrefBranch> prefBranch(do_GetService(NS_PREFSERVICE_CONTRACTID, &rv));
   if (NS_SUCCEEDED(rv) && prefBranch)
     prefBranch->GetBoolPref(SHOW_TRAY_ICON_PREF, &showTrayIcon);
-  if (showTrayIcon)
+  if (showTrayIcon && !mSuppressBiffIcon)
   {
     GenericShellNotify(NIM_ADD);
     mBiffIconVisible = PR_TRUE;
   }

With the checkin from bug 133917, if SHOW_TRAY_ICON_PREF existed then mSuppressBiffIcon is ignored which I do not think is what was intended.
Re comment #0:
> Build ID: 2006-05-05-13 of SeaMonkey trunk under Windows XP.

"Official" SeaMonkey trunk nightly 2006-05-05-09 here, under Win2k.

> Summary: Biff doesn't clear from system tray.

WFM.

> Likely that this is a regression from bug 133917.

Possibly, but I don't see it and I won't know why (yet).

> 1. Receive a new message, and see that you get notification (via popup alert
> notification _and_ system tray).
> 2. Read message.
> 3. If biff still hasn't cleared, click GetMsgs.

As soon as I touch the folder with the new mail, the tray icon vanishes.

All pref items under Notifications are checked, thus my computer beeps, the alert slides up and down and the tray icon appears afterwards. Switching to MailNews (by ALT-TAB or double-clicking the biff icon) takes me to the mail main window, where I select the respective mail folder...

I checked this for IMAP and POP3.
Maybe you ran into this: <http://lxr.mozilla.org/mozilla/source/mailnews/base/src/nsMessengerWinIntegration.cpp#917>

Can someone seeing the bug here check out 133917 locally to see if that helps?

Re comment #1:
> With the checkin from bug 133917, if SHOW_TRAY_ICON_PREF existed then
> mSuppressBiffIcon is ignored which I do not think is what was intended.

You're right. Patch coming.
Attached patch add missing if clause (obsolete) — Splinter Review
Only check the pref when a biff icon is requested.
Assignee: mail → mnyromyr
Status: NEW → ASSIGNED
Attachment #221073 - Flags: superreview?(neil)
Attachment #221073 - Flags: review?(neil)
Comment on attachment 221073 [details] [diff] [review]
add missing if clause

Saving the review for later, unless someone else wants to do it ;-)

>+    nsresult rv;
>+    nsCOMPtr<nsIPrefBranch> prefBranch(do_GetService(NS_PREFSERVICE_CONTRACTID, &rv));
>+    if (NS_SUCCEEDED(rv) && prefBranch)
>+      prefBranch->GetBoolPref(SHOW_TRAY_ICON_PREF, &showTrayIcon);
Nit: as you're changing this, it's not necessary to check both rv and prefBranch so you might as well drop rv and just check prefBranch.
Attachment #221073 - Flags: superreview?(neil) → superreview+
I still wonder why dmose requested the rv check instead of the rv death...
Attachment #221073 - Attachment is obsolete: true
Attachment #221235 - Flags: superreview+
Attachment #221235 - Flags: review?(neil)
Attachment #221073 - Flags: review?(neil)
More precise steps to reproduce:
- make sure you have both sliding alert and tray icon activated
- receive new mail
- see the alert come up and *click the link* on it

At this stage, the tray icon is visible, but this is *not* supposed to have happened here, because the user has already clicked the alert's link! Consequently, the tray icon doesn't go away either...
Except that I don't click the link, so your "more precise" steps aren't necessary, either.
> Except that I don't click the link, so your "more precise" steps aren't
> necessary, either.

Well, your steps are fuzzy enough to not work for me. ;-)

I should update my steps, though:
- make sure you have both sliding alert and tray icon activated
- switch to another application
- receive new mail (check for new mail every x minutes)
- see the alert come up and *click the link* on it

Do you wait for the alert with SM being the currently used app, maybe even with mailnews being the current window? Or do you change to mailnews while the alert is still displayed? 

Either way, the patch here fixes the non-obeying of the mSuppressBiffIcon flag.

 

(In reply to comment #8)
> > Except that I don't click the link, so your "more precise" steps aren't
> > necessary, either.
> 
> Well, your steps are fuzzy enough to not work for me. ;-)
> 
> I should update my steps, though:
> - make sure you have both sliding alert and tray icon activated
> - switch to another application
> - receive new mail (check for new mail every x minutes)
> - see the alert come up and *click the link* on it
> 
> Do you wait for the alert with SM being the currently used app, maybe even with
> mailnews being the current window? Or do you change to mailnews while the alert
> is still displayed? 

Ah, sorry.  Yes; I just tested it without the mail window being focused first, and the taskbar icon goes away fine.  When it _doesn't_ leave seems to be when I've already got the mail window and the message pane focused...
> 
> Either way, the patch here fixes the non-obeying of the mSuppressBiffIcon flag.

Good to know ;-)
Attachment #221235 - Flags: review?(neil) → review+
Checked in on trunk.
(In reply to comment #10)
> Checked in on trunk.

Is there a reason this isn't marked FIXED, now that it has landed on the trunk? 

The only reason was having no windows tinderbox at that moment, but Creature is kinda up again, thus closing. :)
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Verified FIXED with build 2006-05-14-15 of SeaMonkey trunk under Windows XP; all problems seem fixed, thanks!
Status: RESOLVED → VERIFIED
Attachment #221235 - Flags: approval-seamonkey1.1a+
Fix checked in on MOZILLA_1_8_BRANCH.
Duplicate of this bug: 337266
Component: MailNews: Notification → MailNews: Message Display
QA Contact: search
You need to log in before you can comment on or make changes to this bug.