97650 - Windows XP integration for New Mail

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Scott MacGregor]

Just a tracking bug for some work Bhuvan is doing. We want to show the current
number of unread messages for the user's default account in the windows XP login
screen.

Comment 1

[Scott MacGregor]

adding keyword mumbo jumbo

Comment 2

[Markus Gerstel]

Any relationship to Bug 18729 ?

Comment 3

[Scott MacGregor]

this work will happen during .9.5 but is still scheduled to land on the branch.

Comment 4

[grega]

any update?  marking nsenterprise-

Comment 5

[racham]

I have the rough draft of the code that I am debugging right now..Hoping post a
patch soon.

Comment 6

[Jaime Rodriguez, Jr.]

Racham - Status Pls ...

Comment 7

[Jaime Rodriguez, Jr.]

Racham/MScott - Pls enter ETA into Status Whitebaord. We need this one like,
yesterday.

Comment 8

[racham]

Sorry. Got delayed due to some test scenarios.

Will certainly post the patch this evening with all details. Setting ETA to
today and will further update the status white board after attaching patches.

bhuvan 

Comment 9

[racham]

Attachment: mozilla patch, ver 1

Comment 10

[racham]

Attachment: ns patch, ver 1

Comment 11

[racham]

Attachment: patch to be placed in uninstall module (prepared as notes so that Sean Su can pick it and put it in the right place)

Comment 12

[racham]

Adding Sean and Seth to the cc list.

Updating the status whiteboard.

Comment 13

[racham]

Patches posted achieves the following :

1. Writes the unread mail count of the default account (in the Windows registry
and thus) on Windows XP welcome screen
   when 
       a. user launches the mail app and clicks on 'Get Msg' button
       b. biff is triggered
       c. default account is set
       d. user quits mail app

After one of the above actions, user can logoff/switch user to notice unread
mail count on Windows XP welcome screen.

2. No operations are performed for 'nntp' and 'none' type servers.

3. When default account is removed, corresponding registry entry is deleted.

4. When the default account is changed, old account's registry entry is cleared
and new default account's entry is noted.

4. Code is wrapped by XP_WIN to work on Windows only. With in it, native Windows
XP APIs are queried for making other Windows platform to skip the code

5. When the app is left running in account 'foo' and you choose to switch XP
user account to 'bar', as an intermediate step, it brings up welcome screen with
the unread mail count of 'foo'. Now if you wait for the biff time  you set in
the mail app of 'foo', you will see notice the unread mail count going up
dynamically after the biff interval, if any new messages are received.

6. The default format chosen for storing the unread count info in the registry
is the user email address. But there is also provision to prefix any string ISP
wishes to. Look at ns pach for an example. If ISP wants to prefix say 'My ISP:',
then the patch appends the useremail to make it a complete meaningful key like
'My ISP:[e-mail]'.

7. On application uninstall (mozilla or netscape), all the unread count registry
entries written by that application are deleted keeping the registry in clean state.

Points to note :

1. Say mail application 'x' writes the unread mail count in the registry say
using  '[e-mail]' as the registry key (i.e., email address as the registry
key). At later time, say mail application 'y' writes the unread mail count in
the registry for the account with same email adderss (i.e., '[e-mail]'). As
the registry keys are mathcing here, mail application 'y' will overwrite all
corresponding registry data of 'x'.

2. If XP user 'foo' has 2 mozilla profiles say 'xyz1' and 'xyz2'. Let's say,
xyz1's mail account -> [e-mail], unread mail count : 5, when user last
used profile xyz1 and 
xyz2's mail account -> [e-mail], unread mail count : 7, when user last
used profile xyz2.

When user logs out, on welcome screen (under user account 'foo') it says, 
12 unread mail messages. On mouse over, that line becomes clickable. On
clicking, it displays tooltip with the following lines
         [e-mail] (5)
         [e-mail] (7)

________________________________________________________________________________
I will work with Sean to find suitable place for uninstall code.

I have 2 more days left with XP OS, before I get forced to reinstall. Testing
for this can be done XP OS only. I will make optimized builds as well in case we
opt for dll testing.
Seth & Scott, Can you take the first look at the changes and let me know of any
changes. thanks.

bhuvan

Comment 14

[(not reading, please use [e-mail] instead)]

head up, racham and I are re-working this.  we should have something tomorrow.

Comment 15

[(not reading, please use [e-mail] instead)]

Attachment: patch, just plug in the registry code and fix the XXX spots

Comment 16

[(not reading, please use [e-mail] instead)]

bhuvan, 

attached is the frame work for OS integration.  the new code is only built on 
windows.

look for XXX, those are the areas where you need to add registry code or add 
code to get the profile name, the application name (or path?), etc.

I'll comment about the design tomorrow, after some sleep.

Comment 17

[racham]

Attachment: Latest patch, mozilla/mailnews after filling in the registry relevant code

Comment 18

[racham]

I have tested this patch on my XP box with several test scenarios. It worked as
expected.

This patch sets the timer trigger with intervals of 10 sec. 5 seemed very low.
bhuvan

Comment 19

[Scott MacGregor]

Comment on attachment 51191 [details] [diff] [review]
Latest patch, mozilla/mailnews after filling in the registry relevant code

r=msoctt

Can you remove your printf  statements or ifdef DEBUG_bhuvan'ize them? 

is afxpriv.h going to be a standard windows file? i.e. it's not like ATL which mozilla doesn't currently require. just making sure this is going to build on win32 machines that may not have things like atl.

where does ATLASSERT come from? Is that macro going to require ATL support?

Comment 20

[racham]

I will get rid the printf statements.
afxpriv.h is added for the support of bunch of macros needed to
manipulate/convert the data before writing into the registry. I compiled the
code sucessfully on Win2k. I ran some tests and found that things are worknig as
expected. App on Win2k skips all those paths dependent on Win XP APIs and falls
through routines without any adverse effects. I will get hold of someone with
WinNT box to run these changes over and see how the compilation and runtime
activities go.

ATLASSERT is not strictly needed in there as the address of the process obtained
from the  shell is always checked before starting registry manipulation
activities. I will clean that up.

thanks,
bhuvan.

Comment 21

[(not reading, please use [e-mail] instead)]

sorry for the delay, I'll go review.

the initial 5 second delay that I set was for debug purposes only.

we have to bump that way up.

Comment 22

[(not reading, please use [e-mail] instead)]

1) I think we should make the timer interval *at least* every minute, probably
more.  

+// timer is set to kick off every minute
+#define UNREADCOUNT_TIMER_INTERVAL 60000 

2) I want to make sure that the code is written in a way where if we aren't on
Win XP we don't register the folder listener, and we don't bother setting up the
timer.

you don't need firstTime.  

make mSHEnumerateUnreadMailAccounts and mSHSetUnreadMailCount members of
nsMessengerWinMigration

in Init() before we try to do anything, go try to load the module and call
GetProcAddress() to set up those member variables.

if loading the dll or setting the variables fails, we know we're not on winxp,
right?  we should bail out then, that way on win 98 / win2k, we won't setup up
the folder listener and we won't have this timer.


3) this code is not going to work right on non US-ASCII machines.

we convert the profile name to cstring
we treat the app path as a cstring 
we treat the email prefix as a cstring.

for email prefix we should be using: CopyUnicharPref()

Comment 23

[(not reading, please use [e-mail] instead)]

also, instead of your additional change to base/src/nsMsgAccountManager.cpp,

can't we just do this?

<     m_defaultAccount = nsnull;
<     setDefaultAccountPref(nsnull);
---
>     SetDefaultAccount(nsnull);

Comment 24

[Scott MacGregor]

Hey Bhuvan, I think you misunderstand my comments about ATL. I didn't mean it as
an OS thing. ATL support isn't required in mozilla for any windows platform.
When you installed VC there's a checkbox which says whether you want to include
atl stuff. A lot of us removed that checkbox during installation. if you really
are using atl stuff or if afxpriv.h is part of that package then we won't be
able to build this on windows. It's not something you have to test on NT, win2k,
etc. It's something that depends on how you installed VC++. 

I for example do not have the ATL stuff installed so if I can't build your patch
then we have a problem. I'll try it out today.

Comment 25

[Daniel Veditz [:dveditz]]

afxpriv.h is in <vc>\mfc\include -- people who have not installed MFC will not
be able to build.  You need to avoid using this header, or prevent this
component from getting built if people have set the NO_MFC=1 environment variable.

ATLASSERT is from <vc>\atl\include\atldef.h -- ditto above for people who have
not installed ATL. There are so many different asserts available just don't use
this form of it.

Comment 26

[racham]

Reinstalled VC++ without any MFC files. Will build it now with required standard
windows headers by taking out reference to afxpriv.h. 

Comment 27

[Sean Su]

Attachment: Patch #1 to the uninstaller to deal with Bhuvan's feature (ns tree)

Comment 28

[Sean Su]

Attachment: Patch #1 to the uninstaller to deal with Bhuvan's feature (moz tree)

Comment 29

[Curt Patrick (gone)]

Comment on attachment 51283 [details] [diff] [review]
Patch #1 to the uninstaller to deal with Bhuvan's feature (ns tree)

r=curt

Comment 30

[Curt Patrick (gone)]

Comment on attachment 51284 [details] [diff] [review]
Patch #1 to the uninstaller to deal with Bhuvan's feature (moz tree)

r=curt

Comment 31

[Daniel Veditz [:dveditz]]

Comment on attachment 51283 [details] [diff] [review]
Patch #1 to the uninstaller to deal with Bhuvan's feature (ns tree)

>+  subkey  = "SOFTWARE\\$CompanyName$\\$ProductName$\\$UserAgent$\\Main";
>+  winreg.setValueString(subkey, valname, value);

In the comments in the e-mail you sent you said the key was "Mail", although
the code said "Main" as it does here. I assume the comment was a typo, but
I'd like confirmation since "Mail" makes some sense too.

with the keyname confirmed, sr=dveditz

Comment 32

[Sean Su]

Mail, Main... they're all the same thing  :)
Seriously, I meant Main, not Mail.

Comment 33

[Daniel Veditz [:dveditz]]

Comment on attachment 51284 [details] [diff] [review]
Patch #1 to the uninstaller to deal with Bhuvan's feature (moz tree)

sr=dveditz

Comment 34

[(not reading, please use [e-mail] instead)]

bhuvan, perhaps it would be good to specify the timer interval as a hidden pref
(in winpref.js, since this is windows only).  make it a second

// default is 5 minutes, 5 * 60 seconds = 300
pref("mail.windows_xp_integration.unread_count_interval", 300); 

in ::Init(), get the pref once.  if <= 0, return early and do no work.

otherwise, set mIntervalTime = value * 1000;  // convert seconds to milliseconds

this is good because

1)  devel and qa can throttle it down to help with testing.
2)  if there's some problem, we can disable it easily
3)  users, if they want, can turn it off or change the interval, of course, this
will not have UI.

Comment 35

[Sean Su]

FYI: my patches to the uninstaller code have been checked in to both trunk and 
branch.  They are not dependent on bhuvan's patches.  Essentially if there's 
nothing in the UnreadMail windows registry key, then the uninstaller will just 
skip over it.

Comment 36

[racham]

Attachment: updated patch, ver 1, removed all afx references + incorporated Seth's review suggestions

Comment 37

[racham]

Updated patch posted above took care of the comments received from previous
reviews. Results of tests done on XP and Win2k are as expected.

New things to look for in the latest update :

1. afxpriv.h and related requirements are removed. Compiled with VC++ that is
installed with no MFC files. Now windows.h, a standard windows header file, is
the only requierment. 

2. XP native processes' addersses are checked at the beginning so that other
windows platforms can bail out early.

3. Strings are now represented with proper types to hold unicode chars too.

4. Timer interval is controlled with the pref
"mail.windows_xp_integration.unread_count_interval" as suggested by Seth. It is
now set to 5 minutes. Timer will be triggered after every 5 mminutes to capture
the folder message changes. We can certainly experiment to come up with better
timing, if we can derive one.

5. On removing the default account or when changing the default account, we
first removed the old account and then were waiting for timer to kick off to
capture the new default account details. But, I think it is little to longer to
wait (5 minutes or anything in that order) to see new default account taking
charge in updating the count. So, I have added UpdateUnreadCount() call after
the old entry removal is done. Now, the change is immediate and the data we
persent to the user when he/she logs out to reach welcome screen. Comments are
welcome.

Thanks to Scott, Seth, Law & Dan for their input.

bhuvan

Comment 38

[racham]

Attachment: improvements to updated patch version1 - explaination to follow

Comment 39

[racham]

The above posted path (id=51427) is an improvement to updated patch, v1 (id=51397).

At the end of account creation process we are asserting in MessengerWinMigration
as routine RemoveCurrentFromRegistry() registry bailed out due to null email
string (email string is null as prefs have not been written to disk yet). So, I
moved the null check as a pre-requisite for calling this routine. This change
needed to support UpdateUnreadCount() that follows RemoveCurrentFromRegistry().

In the patch, you will find only those 2 routines that are really different from
the last patch wrt file nsMessengerWinMigration.cpp. Those two changes are
adding email string check before calling RemoveCurrentFromRegistry() and
removing the error_failure return from RemoveCurrentFromRegistry() incase of
null email string.

You will also notice nsMsgAccountManager changes. This change is needed to
setting a new valid default account when existing default account is removed.
Today, if we have 2 valid accounts besides Local Folders, on removing the first
valid default account, we promote Local Folders as new default account as it
resides at lower index in the accounts array. Instead, we should go through the
array until we find a valid default account. If none, found it should be set to
default. That's the new change in the nsMsgAccountManager.cpp. Besides helping
MessengerWinMigration to pick up the right correct default account, it also
benifits prevents none/nntp accounts frombecoming default accounts.

bhuvan

Comment 40

[racham]

please read (in the last paragraph of previous update), 

If none, found it should be set to default.

as

If none found, the default account should be set to null.

Comment 41

[Scott MacGregor]

Comment on attachment 51427 [details] [diff] [review]
improvements to updated patch version1 - explaination to follow

r=mscott

Comment 42

[Scott MacGregor]

thanks for taking out the afx stuff Bhuvan!

Comment 43

[(not reading, please use [e-mail] instead)]

looks good.  some minor points:

1)

+    UpdateUnreadCount();
+    NS_ENSURE_SUCCESS(rv,rv);

should that be

+    rv = UpdateUnreadCount();
+    NS_ENSURE_SUCCESS(rv,rv);

2)

don't make mPrefs a member variable of nsMessengerWinIntegration.  just call
do_GetService()
when you need it.  (You only need it on Init() and when the default account
changes, which are rare)
If we don't hold onto it, we don't need a shutdown listener to release our
reference to it.

3)

+ commandLinerForAppLaunch.AssignWithConversion(DOUBLE_QUOTE);
+ commandLinerForAppLaunch.AppendWithConversion(DOUBLE_QUOTE);

should be:

+ commandLinerForAppLaunch.Assign(NS_LITERAL_STRING(DOUBLE_QUOTE).get());
+ commandLinerForAppLaunch.Append(NS_LITERAL_STRING(DOUBLE_QUOTE).get());

4)

+You will also notice nsMsgAccountManager changes. This change is needed to
+setting a new valid default account when existing default account is removed.
+Today, if we have 2 valid accounts besides Local Folders, on removing the first
+valid default account, we promote Local Folders as new default account as it
+resides at lower index in the accounts array. Instead, we should go through the
+array until we find a valid default account. If none, found it should be set to
+default. That's the new change in the nsMsgAccountManager.cpp. Besides helping
+MessengerWinMigration to pick up the right correct default account, it also
+benifits prevents none/nntp accounts frombecoming default accounts.

sounds good, but make sure that you aren't returning failure when you used to
return NS_OK.

I'm worried about some case where returning NS_ERROR_FAILURE will cause an
exception in the account manager js.

can you double check that this won't happen to us now with your change?

fix these small issues, and then sr=sspitzer

Comment 44

[(not reading, please use [e-mail] instead)]

also, with your last patch, you've removed a call to SetDefaultAccount()

I think you want to change:

+ m_defaultAccount = aAccount;

to

SetDefaultAccount(aAccount);

+      if (!foundValidDefaultAccount) {
+        *aDefaultAccount=nsnull;

to SetDefaultAccount(nsnull);

SetDefaultAccount() will set m_defaultAccount, and more importantly, it will
notify any observers that the default account has changed.

Comment 45

[racham]

Scoot & Seth, thanks for your reviews.

I will check the accountmanager issues that have been mentioned. Let me test
some more on that. Also I realiazed that I needed to add profile to requires
list and get rid of ToNewCString() and use get() after UCS2ToUTF8 conversion.
Will post another round of diffs with all new minor changes for records.

bhuvan

Comment 46

[Jaime Rodriguez, Jr.]

Can you pls provide us with the new ETA, for this one?

Comment 47

[racham]

new eta : today [10.01]. Last patch is ready. Running some basic tests.

Comment 48

[racham]

Attachment: updated patch, ver 2 - Seth's suggestions are taken care of

Comment 49

[(not reading, please use [e-mail] instead)]

fix these three lines to use NS_LITERAL_STRING().get() and then sr=sspitzer

commandLinerForAppLaunch.AppendWithConversion(PROFILE_COMMANDLINE_ARG);
commandLinerForAppLaunch.AppendWithConversion(MAIL_COMMANDLINE_ARG);
deleteKey.AssignWithConversion(UNREADMAILNODEKEY);

great work, bhuvan!

Comment 50

[(not reading, please use [e-mail] instead)]

also don't forget to add yourself to the list of contributors to 
nsMessengerWinIntegration.cpp.

Comment 51

[racham]

Attachment: updated patch, ver 3 [& last one] - Added myself to contributors' list and fixed those remaining literal string conversions

Comment 52

[(not reading, please use [e-mail] instead)]

Comment on attachment 51623 [details] [diff] [review]
updated patch, ver 3 [& last one] - Added myself to contributors' list and fixed those remaining literal string conversions

sr=sspitzer

Comment 53

[Scott MacGregor]

Comment on attachment 51623 [details] [diff] [review]
updated patch, ver 3 [& last one] - Added myself to contributors' list and fixed those remaining literal string conversions

r=mscott

Comment 54

[racham]

Checked in on the trunk.

Comment 55

[Scott MacGregor]

Bhuvan can probably provide more detailed testing steps than me but here are a
couple things that jump out at me that we need to explicitly check:

1) If you have an AOL account in NSCP and an AOL client account, we shouldn't
double count the # of unread messages in the login screen. i.e. if you have 5
unread messages for that account, we use the same registry entry key as AOL for
this particular case so the unread message count in the login screen should be 5
and not 10.

2) If you have the same email address in an outlook account and a netscape
account we shouldn't double count the # of unread messages in the login screen.
Just as above, we are matching our registry syntax with that used by OE so
accounts with the same email address aren't double counted.

3) For multiple profiles, you should see us store the unread count for the
default email address for each profile. So if I have 5 unread in one profile and
5 unread in another profile with another email address as the default account,
the login screen should say 10. 

4) In all cases, the login screen shows the total # of unread messages for all
the default accounts for all the mail apps on your system. Bhuvan said that
clicking on this number brings up a new popup on win XP which shows you a break
down showing how many unread messages are for each account. This is a good
technique to use to make sure we are generating the right number for our accounts.

5) Try changing the default account in your profile to another email address.
Make sure we don't leave a reference to the previous address in the winxp login
screen. 

Bhuvan, any other interesting edge cases I didn't mention here?

Comment 56

[racham]

Scott,

Thanks for listing various scenarios. All cases you have mentioned should be tested.

Esther, 

Additional notes & test cases :

1. Our update activities are primarily based on a timer. We have the timer value
set to 5 minutes today (pref "mail.windows_xp_integration.unread_count_interval"
in winpref.js under <install dir>\defaults\pref when you install today's trunk
build from sweetlou). As soon as mail application starts timer gets initialized.
From that point after every 5 minutes it checks to see if the unread message
count of the default account is changed. When the timer comes back after 5
minutes, if a change is noticed (say user read some messages within 5 minutes), 
windows registry is updated with new unread mail count.

Scenario : User 'foo' started mozilla with profile say 'test'. The default mail
account is say '[e-mail]'. As soon as mail app is launched timer is
initialized. Unread mail count is initialized to -1. User logs into the mail
account and finds 10 unread messages to start with. User reads 4 messages and
then say he moved onto activities like replying to a message or browsing. After
5 minutes, timer triggers the action to check unread mail count. It gets the
latest unread count then. This time the unread count is 6. App compares it with
last unead count it registered which is -1 in this case. Noticing the disparity,
it proceeds further to records the last unread count as 6 now and updates the
registry with the same.  If the user sticks around for 5 more minutes, the
unread count then is compared with 6 and updates registry if needed.

Say user logged out of the session after the first trigger without doing any
further activities. On the welcome screen he/she will find 6 unread mail
messages under account name 'foo'.

Another point to note here is, say some 3 more messages have arrived (via biff
or Get Msg button click) after the first trigger and user quits before the
second trigger happens. In this case, as we close the app, we check one more
time to see if the unread countis changed. It will notice that the unerad count
has gone up by 3 and records that in the registry and quits. So, on the welcome
screen user will find 9 unread mail messages.

If user logs in, launches mail app, reads couple of messages and and quits
before the first timer trigger happens, app never gets a chance to record the
unread count as atleast one timer trigger has not occured.

So, interval for the timer plays a very important role here. As testing
engineers embark on testing this feature we need their help in determining the
optimal timer interval which will allow us to display the info on welcome screen
as accurate as possible and at the same time not to slow the down the app.
Please come ack with suggestions as to what might an optimal timer interval. 5
minutes is the current value. You can always change the value in winpref.js and
experiment.

2. If an AOL is the default account for a given profile, when we register it's
information, we will registry with the key "America Online -
<[e-mail]>". We follow this format so that we don't duplicate the count
as Scott explained in his update.

If user quits before the timer trigger happens, all the activity that happened
in that last 5 minuts window is not recorded.
3. Another case to test is to removing the default account.
There are 2 scenarios here. 

  a. User has multiple accounts. Say one imap account and one pop3 account. Say
user used Imap account as the the default account for a while. User deletes the
imap account. So, the next valid default account is the pop3 account. So, on the
welcome screen, user should notice the reference to imap is gone and pop3
account reference appears.

  b. User has a single account. Say he/she has a pop3 account. User deletes that
account and reference of that account from the welcome screen is gone. We will
no  more unead count messages for this profile until a new default account is added.

  Note : Nwes and Local Folders, though can become default accounts, they are
not valid candidates for this feature. So, if we arrive at a situation where
either of them is a default account, we simply don't do anything for that profile.

4. Other windows platforms (win2k, NT, 98, 95) should not be affected by this
feature. They should continue to work as they used to. Same applies to Mac and
Linux builds too. 

Please let me know if you have any questions.

bhuvan

Comment 57

[racham]

One thing I forgot to mention is that if you delete or change your default
account, the registry updates happen immediately without waiting for the timer
trigger. So, the info displayed on the welcome scren should reflect that change
immediately.

Remember for the count of the default account to show, user must launch the app
with a profile and login into default account and get messages. The unerad
message count will be displayed if there the number of messages is 1 or more.

For the benifit of those who do not have XP OS installed, I am going to post a
screenshot which reflects what Scott mentioned in #4 of his update. Screenshot
coming up..

Comment 58

[racham]

Attachment: screenshot - XP welcome screen with tooltip displaying the split of unread mail count

Comment 59

[Jaime Rodriguez, Jr.]

we'd sure like this one for the branch, but time is running out.

Comment 60

[racham]

Attachment: improvement patch, ver 1, if the user quits before the timer is triggered, update the registry with latest unread count

Comment 61

[racham]

Today, if the user brings up the mail app and gets his/her mail and read couple
of messages and quit the app before the first timer action is triggered, app
will not get the opportunity to update the registry latest unread count thus
displaying essentially the previous sessions's data. That is not desirable. 

So, we can avoid that situation by updating the registry first time the total
unread count is changed. That will update the registry to reflect the first user
action that alters unread mail count. As the user reads some of the messages,
the latest unread mail count is kept track of. Now, if the user quits before the
first timer is triggered, the registry is updated one last time via
UpdateRegistryWithCurrent() as we will have all information needed avialable to
do so.

Comment 62

[(not reading, please use [e-mail] instead)]

Comment on attachment 51819 [details] [diff] [review]
improvement patch, ver 1, if the user quits before the timer is triggered, update the registry with latest unread count

nice work.

Comment 63

[Scott MacGregor]

Comment on attachment 51819 [details] [diff] [review]
improvement patch, ver 1, if the user quits before the timer is triggered, update the registry with latest unread count

r=mscott

Comment 64

[Scott MacGregor]

Esther is still trying this out in the trunk. She hasn't found any problems yet
so we should be ready to talk about it at the Wednesday PDT meeting. 

Comment 65

[racham]

attachment 51819 [details] [diff] [review] checked in on the trunk.

Comment 66

[esther]

Using the trunk build 10-02, I found with my winxp, that it will only list (3)
default accounts on the Welcome Page.  Note: it will list the unread count for
all the profiles default mail acconts but only (3) of the accounts are listed,
giving the impression the count is wrong. 

Comment 67

[esther]

Bhuvan and I tested this more and found that WinXP OS has a limitation of only
listing 5 mail accounts on the Welcome Page for unread message count.  However,
it will update the count with all the accounts so in some cases (where user has
more than 5 default mail accounts) the count may differ from the number shown
for each of the displayed accounts.  This is not  a bug and should be released noted

Comment 68

[esther]

I finished trunk testing, it passes.
Using Trunk build in (2) different XP user profiles (1 & 2). I created (5)
Netscape 6 profiles in XP profile 1 and (2) Netscape Profiles in XP profile 2. 
This gave me 5 default mail accounts with unread counts in XP profile 1 and 2
default mail accounts with unread counts in XP profile 2.  
I read messages in various accounts and verified the updated counts.
I reassigned the default mail account in Netcape 6 profiles and verified the
updated account displayed on the Welcome Page.
I removed default mail accounts and verified they were removed from the Welcome
Page and in the case where another account became the default, I verified it was
now listed.
I Switched Users and verified the Unread counts for both XPUsers.
No crashes or problems (just confusion due to XP limitation of (5) accounts
displayed per XP User).  I used build from 10-2 and 10-3 with the time limit fix.
This fix passes.

Comment 69

[esther]

Also note:  I had Outlook Express accounts too that were listed if they fell
within the 1st 5 accounts and their unread counts were counted.

Comment 70

[Jaime Rodriguez, Jr.]

pls check it in - PDT+

Comment 71

[racham]

Checked in on the branch.

Marking Fixed.

Comment 72

[esther]

verified fixed on branch too.