Closed Bug 384701 Opened 17 years ago Closed 17 years ago
Mailcompose erroring out on migrated profile
On my notebook machine, I have a profile with 2 IMAP accounts, Local Folders, and a newsgroup account only. After I migrated this profile from SeaMonkey 1.1.2 to trunk, I can't get a mailcompose window up any more, no matter if I try to reply on some mail/post or compose a new message. It always errors out with that nice little dialog telling "An error occurred while creating a message compose window. Please try again." In the Linux console, I found the following exception at this point: XXX ex EX: = [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIMsgIncomingServer.serverURI]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: compareAccountSortOrder :: line 2263" data: no] ComposeUnload from XUL I repeatedly get this when trying to open mailcompose again. The XUL error console has 3 warnings at this time, all about redeclations of properties in ComposerCommands.js (prompt, promptUsernameAndPassword, promptPassword) but I'm told this is known, and I think it's probably not the problem here. A new profile with just a news.mozilla.org account created works fine in the same build.
Oh, and this is a quite recent self-compiled trunk build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/2007061516 SeaMonkey/2.0a1pre
Hah, actually, I just realized there _is_ an additional account in the original profile I migrated from, and it's a movemail account! This account does _not_ show up in the migrated profile's account manager or folder pane, it might not be correctly migrated (Mark?) and cause the problem.
Hmm, this might really turn out to be connected with movemail - apparently there's a problem with movemail in SeaMonkey trunk anyways, maybe this would be resolved with that. When I create a movemail account in a default trunk profile, it doesn't show up anywhere - not even in about:config. Still, I think we should fail to show a mailcompose window at all when reading info from one account fails.
This looks like a regression from bug 379070 (nothing to do with migration). Though I haven't tested the fix with movemail in this way to be sure. It should fix movemail account migration/viewing at least. Basically we changed the GetLocalStoreType function from a char** to nsACString& but missed movemail, so it defaulted to the one provided in nsMsgIncomingServer. I got these when trying to create a movemail account, which pointed me to the solution: ###!!! ASSERTION: nsMsgIncomingServer superclass not implementing GetLocalStoreType!: 'NotYetImplemented', file /mozilla/master/mozilla/mailnews/base/util/nsMsgIncomingServer.cpp, line 918 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file /mozilla/master/mozilla/mailnews/base/util/nsMsgIncomingServer.cpp, line 337 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file /mozilla/master/mozilla/mailnews/base/util/nsMsgIncomingServer.cpp, line 384 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file /mozilla/master/mozilla/mailnews/base/util/nsMsgIncomingServer.cpp, line 166
Comment on attachment 268983 [details] [diff] [review] Fix movemail's GetLocalStoreType function nice find!
I've checked the patch in, Robert when you get chance can you see if this fixes your problem or not?
Yes, it works. Mailcompose works and the movemail account shows up everywhere and is usable. Marking FIXED as I'm the reporter and the patch fixed it for me.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.