Closed
Bug 336831
Opened 19 years ago
Closed 19 years ago
Biff doesn't clear from system tray.
Categories
(SeaMonkey :: MailNews: Message Display, defect)
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)
1.27 KB,
patch
|
neil
:
review+
mnyromyr
:
superreview+
iannbugzilla
:
approval-seamonkey1.1a+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 2•19 years ago
|
||
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.
Assignee | ||
Comment 3•19 years ago
|
||
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 4•19 years ago
|
||
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+
Assignee | ||
Comment 5•19 years ago
|
||
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)
Assignee | ||
Comment 6•19 years ago
|
||
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...
Reporter | ||
Comment 7•19 years ago
|
||
Except that I don't click the link, so your "more precise" steps aren't necessary, either.
Assignee | ||
Comment 8•19 years ago
|
||
> 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.
Reporter | ||
Comment 9•19 years ago
|
||
(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 ;-)
Updated•19 years ago
|
Attachment #221235 -
Flags: review?(neil) → review+
Assignee | ||
Comment 10•19 years ago
|
||
Checked in on trunk.
Reporter | ||
Comment 11•19 years ago
|
||
(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?
Assignee | ||
Comment 12•19 years ago
|
||
The only reason was having no windows tinderbox at that moment, but Creature is kinda up again, thus closing. :)
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 13•19 years ago
|
||
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+
Assignee | ||
Comment 14•18 years ago
|
||
Fix checked in on MOZILLA_1_8_BRANCH.
Keywords: fixed-seamonkey1.1a,
fixed1.8.1
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.
Description
•