Closed Bug 100385 Opened 23 years ago Closed 22 years ago

Turbo, adding a second account w/ same server and folders gone/messages gone

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

x86
Windows ME
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: nbaca, Assigned: cavin)

References

Details

(Whiteboard: [ADT1])

Attachments

(1 file, 2 obsolete files)

Branch build 2001-09-17-03: WinMe

Overview: Migrate 1 profile, exit/restart, migrate a 2nd profile with an IMAP
account and no account information appears. In fact the Account Wizard opens
prompting the user to create an account.

Steps to reproduce:
1. Start the application and when Profile Manager appears, select a profile to
migrate (Notice that the Quick Launch/Netscape icon appears in the system tray).
2. After the browser opens, then open Mail
3. The mail account should appear in the folder pane
4. File|Exit (the Quick Launch icons remains in the system tray)
5. Start the application again and when Profile Manager appears, select a
profile that has an IMAP account.
6. After the browser opens, then open Mail

Actual Results: 
- No account appears in the folder pane and the Account Wizard appears prompting
the user to configure an account. Also the Account Settings dialog displays no
mail account.
- Exit/Restart (Quick Launch icon still in the system tray), open Mail and still
no account information appears.
- Exit the application
- Exit the Quick Launch icon via its context menu
- Restart, open Mail and NOW the account appears in the folder pane, account
information appears in the Account Settings dialog and the Account Wizard does
not appear (as expected).

Expected Results: After step 6, it should display the account in the folder and
in Account Settings. You should also be able to retrieve and send messages.

Additional Information:
- If the second account migrated has a POP account then it appears ok. It's the
IMAP accounts that display this problem.
Marking nsbranch because this could be perceived as data loss, unless the user
knows to turn Quick Launch off.
Keywords: nsbranch
Summary: Quick Launch, migrate a second account that's IMAP and no acct info appears → Turbo: Quick Launch, migrate a second account that's IMAP and no acct info appears
cc: trudelle since this is turbo
If this only fails using QuickLaunch, shouldn't it be assigned to ccarlen?
Blocks: 75599
taking it
Assignee: racham → ccarlen
Ninoschka - are the IMAP accounts in the 1st and 2nd profile the same or different?
Status: NEW → ASSIGNED
I hope this makes it more clear:
- First migrate a profile with a POP or IMAP account.
- Exit
- Then migrate a second profile which has an IMAP account (If the first profile
had an IMAP account then this second profile would use a different IMAP account
than the first)

plusins this one because it is on Trudelle's short list. Placing "Turbo+" in
Status Whiteboard for short list query.
Keywords: nsbranchnsbranch+
Whiteboard: Turbo+
turning off multi-profile turbo, so this is -
Keywords: nsbranch+nsbranch-
nominating assuming turbo gets turned back on in the future.
Keywords: mailtrack, nsbeta1
-> 0.9.7
Target Milestone: --- → mozilla0.9.7
Blocks: 107067
Keywords: nsbranch-
Blocks: 108795
Ninoschka, Can you try this again with a current trunk build and see what the
status is? I need to look at this again and, as I remember, I couldn't repro it.

I'll try to reproduce with one of the latest builds.
I just reproduced using 2001112903 win32 build under win2k. However, I
reproduced while running with and WITHOUT turbo mode. So I'd say this isn't a
turbo mode bug.

Here's what I did:

1. Went into Communicator 4.76 and made the only profile there access my
yahoo.com mail via POP
2. Created a second profile in Communicator 4.76 which accessed my IMAP mail on
nsmail-1. NOTE: I didn't not login to nsmail-1, so d:\program
files\Netscape\Users\pchen_imap\Mail\ is empty.
3. Deleted mozilla directory in d:\Documents and Settiongs\pchen\Application Data\
4. Startup Mozilla (it was installed with turbo mode on)
5. Profile manager appears, select profile with POP mail (profile gets converted)
6. Browser window shows up (turbo icon appears in tray)
7. Close browser window (turbo mode alert pops up)
8. Run Mozilla Profile Manager via start menu (Start->Programs->Mozilla->Profile
Manager)
9. Profile manager apperas, select profile with IMAP mail (profile gets converted)
10. Browser window shows up
11. Close browser window (don't remember if turbo mode alert pops up)
12. Double click on mozilla sys tray icon
13. Profile manager appears, select profile with POP mail acct.
14. Once browser window appears, open mail window
15. Notice mail account appears in folder pane.
16. Select File->Exit (don't remember if turbo mode alert pops up)
17. Double click on mozilla sys tray icon
18. Profile manager appears, select profile with IMAP mail acct.
19. Once browser window appears, open mail window
20. Notice no mail account in folder pane and Account Wizard shows up.

Now turn off turbo mode, and repeat steps 3-20 except you launch mozilla via a
different method in steps 12 and 17 since turbo mode isn't on. You will get the
same result (well, minus the turbo mode alerts).

My hypothesis is that since I didn't login to the IMAP account in communicator,
the migrated mozilla profile has an empty ImapMail folder. Sounds like a mail
profile migration issue to me.
Changing component to Profile Migration and removing turbo/quick launch
references. ;-)
Assignee: ccarlen → sspitzer
Status: ASSIGNED → NEW
Component: Account Manager → Profile Migration
QA Contact: nbaca → esther
Summary: Turbo: Quick Launch, migrate a second account that's IMAP and no acct info appears → migrate a second account that's IMAP and no acct info appears
Whiteboard: Turbo+
Removing block on bug 75599
No longer blocks: 75599
Blocks: 75599
Comment #13 is logged in bug# 100414: If the 4.x profile does not have mail
configured, try and migrate it into 6.x and you are unable to configure a mail
account. 

The problem described in this bug is different from Comment#13 because it
happens with profiles that have mail configured in 4.x and using turbo. If I
turn turbo off then I have no problems migrating and viewing email. I was able
to reproduce the problem using two different accounts on the same server (trunk
build 2001-12-03-03 build on WinMe):

1. In 4.x I have a profile configured for qatest22 on nsmail-2 (IMAP)
2. In 4.x I have a second profile configured for qatest20 on nsmail-2 (POP)
3. I delete all 6.x profiles and registry files
4. Double click on Netscape6.exe and choose the qatest22 profile to migrate
5. When the browser opens go to Preferences, Advanced, OK, File|Exit and a
message states that it will start Quick Launch (aka turbo)
6. Double click on Netscape6.exe again and it opens to the browser again, start
Mail, login to mail and messages display, as expected.
7. Exit
8. To migrate the second account use the "-installer" flag and choose the second
account (qatest20)
9. It opens the browser, then open Mail

Actual Results: No mail accounts appear in the folder pane and the Account
Wizard appears.
Expected Results: The mail account should be present in the folder pane and a
password dialog should appear.
paul, based on ninoschka's comments, this sounds like a turbo bug again.

bouncing back to paul.
Assignee: sspitzer → pchen
It may be caused by turbo, but the end result is:

Actual Results: No mail accounts appear in the folder pane and the Account
Wizard appears.

It's an account mgr problem. Regardless of who's to blame here, I think the
problem would most likely be solved by an account mgr person. If, after that, it
does turn out to be directly caused by account mgr startup->shutdown->startup,
I'll take it back.
Assignee: pchen → sspitzer
Component: Profile Migration → Mail Window Front End
reassigning to racham.
Assignee: sspitzer → racham
QA Contact: esther → nbaca
moving to 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Trunk 2001-12-03: WinMe
A couple more scenarios that I tried:

1. In the second profile when mail is configured no folders appear yet the
account information is correct in Account Settings. After an exit/restart then
the account appears in the folder pane.
- Profile1: qatest20/nsmail-2
- Profile2: qatest20/nsmail-2 (account & folder information gone from folder pane)

2. This scenario uses one profile. I log in successfully but messages do not
appear in thread pane yet the message count in the status bar shows a count.
- Profile1: qatest32/nsmail-1 (POP) and qatest33/nsmail-1 (IMAP)

Changing Summary to closer reflect the issue. Changing Summary from "migrate a
second account that's IMAP and no acct info appears" to "Turbo, adding a second
account using the same server and folders gone/messages gone"
Summary: migrate a second account that's IMAP and no acct info appears → Turbo, adding a second account w/ same server and folders gone/messages gone
Keywords: nsbeta1nsbeta1+
Priority: -- → P2
Status: NEW → ASSIGNED
I have tried migrated 2 IMAP acounts one after another with and without turbo mode.

Without turbo mode, I was able to migrate these 2 profiles successfully and find
both accounts when mail app is launched.

With turbo mode, I was able to migrate these 2 successfully 80% of the time.
Couple of times when it failed, I have noticed the mail app used the first
profile's info even after migrating the second profile (and using it to launch
the app). However, I could not reproduce this again. Also, I have noticed that
some icons are missing and buttons are jumbled. This is reproducible and I filed
bug http://bugscape/show_bug.cgi?id=11609 for that. 

Ninoschka, Were you able to reproduce some/all of these problems with/without
turbo consistently ? At least in my case, I haven't noticed any problems in
non-turbo mode.
Trunk build 2001-01-04-03: WinMe, problems continue...

Used these accounts during testing:
qatest32/nsmail-2 (i.e. 32)
qatest33/nsmail-1 (i.e. 33)
qatest20/nsmail-1 (i.e. 20)

1. Turbo on
a.* Migrated 32, exit. Migrate 33 and when Mail opens the Account Wizard appears. 
- Basically no account appears and it is not present in Account Settings as well.
- Tried a second time and this time instead of displaying 33 it displayed 32,
just as Bhuvan described.

b.* Migrate 20, exit. Create new profile for 20 and no account and no folders
appear. Exit/restart and now it appears ok. Then when composing a message the
From identity displayed "...".

c. Migrated 32, exit. Restart same profile and added 33 and it works as it
should, no problems.
Sofar all reported problems have been with turbo mode turned on. I am going to
try Ninoschka's test cases and will try to gather any clues. This may land back
in Conrad's court. For now, I will investigate further. Moving to mozilla0.9.9.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Turning QuickLaunch on by default is by far the most important single
performance enhancement in MachV. It is critical that we not let this continue
to slip, but rather make a stand now, and nail this in 0.9.9.  Could we please
set the priority field to reflect this?
I think the priority is fine.
Sorry, I'd swear the priority field was blank when I entered the comment, but
bug activity shows otherwise. P2 is okay.
No longer blocks: 107067
sorry this got pushed out again, but there was some feature work and P1 bugs
that had to come first.
Target Milestone: mozilla0.9.9 → mozilla1.0
Note, there is another bug for Profile confusion 128386 which has been nominated
but has no milestone.  Since QA requires multiple profiles to test different
settings in different proliles, this bug and 128386 makes it difficult to switch
between profiles to accomplish this testing.  To trust testing in a profile, we
have to disable Quick Launch, bring up Profile Manager select another profile,
launch the other profile, then turn on Quick Launch,  exit the  app, then launch
again in order to test Quick Launch while testing mail.  Please fix these bugs
so we can test this feature adequately while testing mail.
reassigning to Cavin.  Raising priority.
Assignee: racham → cavin
Status: ASSIGNED → NEW
Priority: P2 → P1
The problem is that 'mail type' stored in object nsMessengerMigrator never gets 
changed even if the type is going to be different because a new profile is to be 
launched/migrated (ie, you're in an POP profile and you are about to migrate an 
IMAP profile). 'mail type' is initialized once when a new profile is opened or 
migrated. In non-turbo mode this works fine because we never get a chance to 
launch a second profile at all. But in turbo mode this should be changed based 
on the new profile which is going to be launched or migrated.

A patch is coming.
Attached patch Proposed patch, v1 (obsolete) — Splinter Review
good catch. and this looks like the right place to do it, unless convention is 
to register an observer on the "change profile" event.  maybe ccarlen can 
comment on that.

but it looks like there are two other member variables which need to be cleared.

  PRInt32 m_oldMailType;
  PRBool m_alreadySetNntpDefaultLocalPath;
  PRBool m_alreadySetImapDefaultLocalPath;
  
(the other member variables look safe)

can you investigate, and if those need to be reset, can you attach a new patch?
Thanks for catching this!
> unless convention is to register an observer on the "change profile" event

If it's only the change of this pref that needs to be updated when the profile
changes, register a pref-changed callback rather than observing profile changes.
If you do this, you'll get two notifications on a profile switch: one when the
pref service clears the pref on the profile being shut down and another when the
new prefs are read and they have a value for that pref. Sort of an unset
followed by a set.
based on ccarlen's comments, I don't think we need either.

I think cavin's approach is fine, on upgrade, re-initialize the state (by 
resetting or re-getting those three member variables.)
Attached patch Proposed patch, v2 (obsolete) — Splinter Review
Reset two other vars and make a new function to reset all control vars.
Attachment #73565 - Attachment is obsolete: true
see

nsMessengerMigrator::Init()

we call:

  rv = m_prefs->GetIntPref(PREF_4X_MAIL_SERVER_TYPE, &m_oldMailType);
  return rv;

I think that we should remove that and make Init() call your new method.

// necessary for turbo
rv = ResetState();
return rv;

we should then remove these from the ctor:

  m_oldMailType(-1),
  m_alreadySetNntpDefaultLocalPath(PR_FALSE),
  m_alreadySetImapDefaultLocalPath(PR_FALSE)

since ::Init() will be calling your new method, we should make your new method 
return a nsresult, so that it will behave the same as before.

on failure to get the pref, I think reset state should set m_oldMailType to -1.

does that make sense?
Make Init() call the new ResetState() function.
Attachment #73718 - Attachment is obsolete: true
Comment on attachment 73765 [details] [diff] [review]
Proposed patch, v2

r=bhuvan
Attachment #73765 - Flags: review+
Comment on attachment 73765 [details] [diff] [review]
Proposed patch, v2

sr=sspitzer
Attachment #73765 - Flags: superreview+
Whiteboard: [ADT1]
Comment on attachment 73765 [details] [diff] [review]
Proposed patch, v2

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #73765 - Flags: approval+
Fixed in trunk.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Trunk build 2002-03-22: WinMe

Ran all scenarios listed in Comment# 23.
Reopen, since scenario 1b fails.


1a. Success. Migrate 32, migrate 33, I can see all accounts, folders and 
messages.

1b. Fails. Migrate 20, new profile 20, Folder pane is blank yet account info is 
in Account Settings. Even after an exit/restart. I also added another account 
but still no accounts appeared in the folder pane.

1c. Still ok. Migrate 32, exit/restart, add 33, I can see all accounts, folders 
and messages.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
> 1b. Fails. Migrate 20, new profile 20, Folder pane is blank yet account info is 
in Account Settings.

This is bug 99117. There is a patch there awaiting review.
Marking fixed since items 1a and 1c are fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Verified Fixed, thanks!
Status: RESOLVED → VERIFIED
No longer blocks: 75599
Blocks: 75599
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: