Closed Bug 337052 Opened 15 years ago Closed 15 years ago
Center biff functionality in ns Messenger OS2Integration
Ever since the checkin(s) from bug 226270 the WarpCenter biff functionality on OS/2 was broken. I have a patch that reactivates it.
The main change is in nsMessengerOS2Integration::OnItemIntPropertyChanged where one needs to wrap the tests on nsIMsgFolder::nsMsgBiffState_ within a check for (aProperty == mBiffStateAtom). When the method gets called with (aProperty == mTotalUnreadMessagesAtom) the number actually means a message count and not just the message state. The question I still have is if I have to test for the server type or if nsMessengerOS2Integration::OnItemIntPropertyChanged only gets called for POP3 and IMAP servers anyway. The cleanup in this patch is largely cosmetic, as usual the file had inconsistent leading blanks. I also renamed pUnreadCount to pUnreadState as we also set state changes (to keep track of the unread number of messages is unnecessary for the WarpCenter functionality).
Neil, perhaps you can tell me if I need to test for the server type...
Status: NEW → ASSIGNED
Sorry for breaking biff on OS/2; I did't realise that the other platforms happened not to break because they had the atom test. (In reply to comment #2) >Neil, perhaps you can tell me if I need to test for the server type... I wouldn't; the other platforms don't test, plus if we should decide to support a new server type (webmail perhaps) then we would want biff to work there too.
Comment on attachment 221234 [details] [diff] [review] Fix it and clean up > NS_IMPL_ADDREF(nsMessengerOS2Integration) > NS_IMPL_RELEASE(nsMessengerOS2Integration) > > NS_INTERFACE_MAP_BEGIN(nsMessengerOS2Integration) >- NS_INTERFACE_MAP_ENTRY_AMBIGUOUS(nsISupports, nsIMessengerOSIntegration) >- NS_INTERFACE_MAP_ENTRY(nsIMessengerOSIntegration) >- NS_INTERFACE_MAP_ENTRY(nsIFolderListener) >+ NS_INTERFACE_MAP_ENTRY_AMBIGUOUS(nsISupports, nsIMessengerOSIntegration) >+ NS_INTERFACE_MAP_ENTRY(nsIMessengerOSIntegration) >+ NS_INTERFACE_MAP_ENTRY(nsIFolderListener) > NS_INTERFACE_MAP_END Or consider using NS_IMPL_ISUPPORTS2(nsMessengerOS2Integration, nsIMessengerOSIntegration, nsIFolderListener)
Neil, thanks for your hints, I take them both into account in this new version of the patch. Btw, the most suprising thing is that it took OS/2 users so long to complain about the bug and someone to find out how the status is communicated to the system to get me something concrete to look for. I didn't even know about this class three weeks ago... Mike, if you are happy with this, I think we can use the patch on trunk and both branches.
I thought the WarpCenter could actually show a count of messages when you hover over it or something, and that's why I was setting the number of unread and not just the state?
I hope it doesn't because that would complicate matters a lot. (I do not have a WarpCenter around at the moment for testing but nobody mentioned that before.) This http://groups.google.de/group/netscape.public.mozilla.os2/msg/d1ccc45ab022d8ab?dmode=source&hl=de is an old message that you obviously posted when you had originally implemented the feature. From that it seems that the actual number of new messages was never shown. The only other program that I know that makes use of this shared memory object (HBMozillaMail for the XCenter from http://www.os2usr.org/xcenter/) also only shows new mail when it is set to 1 and shows "no mail" otherwise. At least that's what I see in its sources.
Comment on attachment 222316 [details] [diff] [review] Updated per Neil's comments cool these are platform specific, So I'll approve them
Comment on attachment 222316 [details] [diff] [review] Updated per Neil's comments The tree is closed for 188.8.131.52 and this didn't make it... moving approval to 184.108.40.206.
Attachment #222316 - Flags: approval220.127.116.11+ → approval18.104.22.168?
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment on attachment 222316 [details] [diff] [review] Updated per Neil's comments approved for 1.8.0 branch, a=dveditz for drivers
Attachment #222316 - Flags: approval22.214.171.124? → approval126.96.36.199+
You need to log in before you can comment on or make changes to this bug.