I searched the bugs list and found no mention of this, so I am submitting it as a new bug report. I have removed all previous versions of Mozilla and remove all previous user profiles, then installed Mozilla 0.9.9+ (nightly build 2002031408) and created my mail and news accounts from scratch. I am able to connect to the news server news.ecomstation.nl and subscribe to groups, but when I open a group and attempt to compose a message I get a dialog with the following error: An error occurred while creating a message compose window. Please try again. [ Note that the "[" is part of the error message and it appears on a second line in the dialog. The same error occurs when I open my mail account and attempt to compose a message there. This has previously worked with the initial release of Mozilla 0.9.9 for OS/2.

-->varada

This issue has apparently been resolved by nightly build: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:0.9.9+) Gecko/20020318 Mail and news compose windows have been found to display correctly with this newest build.

After additional testing it has been found that this error still can occur in some cases with Mozilla 0.9.9 nightly build 20020318 for OS/2. When using "turbo mode" and the "default" profile (ie. starting Mozilla with the options "-P default -turbo", then opening Mozilla with another user's profile, any attempt to compose an email or news message results in the original error as below: An error occurred while creating a message compose window. Please try again. [ However if Mozilla is not started in "turbo" mode and is instead started only with the specific user's profile, then composing a mail or news message works properly.

I'm not sure I understand. -P is not honored with -turbo. Here is what I did. I created two users, default and new. I started mozilla like this: mozilla -P default -turbo Then I went to another OS/2 window and typed: mozilla -P new Then I went to New Message, and it came up correctly. Is this what you did? Were you using classic or modern?

let me add that i am seeing this on both win32 and linux builds on occasion, but the scenarios are not as mentioned. My occurences involve Replying to a message. Trying to isolate the problem and provide a duplicatable testcase. Will post as soon as i can isolate the problem. but this does occur frequently using daily trunk builds and Replying to a message. Attached is the captured error message. trix

changing QA Contact to myself, since i can duplicate this problem. Also changing bug status Unconfirmed to New.

since able to duplicate on Win32, OSX, & Linux builds. changing OS to ALL, also, CC'ing Lisa Chiang & Gayatri Rimola.

May be good to get this on the nsbeta1 radar after an isolated test case. This bug prevents the user from replying to a message.

was able to isolate a testcase to duplicate this error message. but because the steps are completely different, i entered a new bug (bug 133861). although the error message is the same, i don't get the impression that they are the same problem. trix

because this description seems to be specific to this OS, and a bug was entered with a testcase duplicatible on all platforms, renaming the OS back to OS/2. trix

I've just had this happen in Linux build 2002040408. The conditions are different from bug 133861; the folder I'm attempting to reply from is my inbox on an UW IMAP 2000c server. The message is identical except for the final character, which is "R" instead of "[". I have composed messages previously in this instance of mailnews.

The error may have been localized to that build; I'm currently able to compose, reply and forward using Linux 2002040508.

Is this a frequent enough occurrence to nominate? Peter Janes: using a new build, you don't see this problem on the same message you were seeing the problem on?

That's correct, the new build is fine. For the record, once it started the problem affected all compose windows (new, reply, forward) for all messages in all folders, not just a particular message or set of messages.

Yes, this happens on my Win ME machine with the Classic theme... but not the Modern theme.

Frequently occurs on Win2K with build 2002032603 when replying to a message in my Imap Inbox. Have to fully quit Mozilla, including systray icon. A fresh copy of Mozilla may work ok for some time.

I've been having this bug with various nightly builds (like 2002041721) and the RedHat RawHide mozilla-0.9.9-7 build. I don't get a '[' on the end of the message, instead I get a 'T'

Changing back to All since we have non OS/2 people seeing this.

I've been seeing this same behavior for months on Windows XP. I'm currently running RC1, and I think it would be worthwhile to point out that I have no email accounts configured since I am not using Mozilla for email. Whenever I accidentally click on an email link, this error window shows up. The 'magic letter' in my error box is a 'T', and has been as long as I can remember.

The problem described in #20 is becuase of the fact that you have no account and no identity. When you accidentally click on a link - it brings up the compose window or tries to but since it has no identity it fails to do so and throws up the error dialog box. I have a similar bug 70540 for this and am working on it. Though the bug is about importing mail etc.. the underlying problem is the same. The fix would be to have the Account Wizard come up and notify the user that he doesnt have an account yet. You could prevent all of this happening by merely installing without adding mail. *** This bug has been marked as a duplicate of 70540 ***

Hold on--when I saw this problem I already had mail configured with two separate accounts, and I was attempting to use one of them. (See my comments #12, #13 and #15 above, and another mail user's comment #17.) The only difference was the "magic letter"; news accounts weren't involved at all.

I have started seeing this recently on forwarding inline on various messages. Forwarding these same messages as attachments is successful. The first time I encounter this problem, I get a compose window which didn't have any content in the body of the compose window. So, I close the compose window and choose to forward again. Then, I get an error msg: "An error occurred while creating a message compose window. Please try again." Win2k branch 1.0.1 build. I started experiencing this in yesterday and today's build.

Removing the .msf file from the folder containing this message didn't help.

My compose window is set up so that: 1. it automatically bcc's me 2. I have a reply-to set 3. I have a signature When I first see a blank window, I see three TO: headings in the recipient list and nothing else. So I close the compose window after a few minutes. Then, I get the error msg.

May be getting closer to steps... I had mentioned to putterman that I saw this problem today after I undeleted a message and tried to forward it. He tried something similar and saw the problem. In his case, he had a crash prior to seeing the problem, but I didn't. from putterman: just reproduced! from putterman: I undeleted a message. from putterman: then I forward it and crashed from putterman: When I started up, I tried forwarding the message again and got the error. from putterman: Both times it's happened to me I've crashed prior to seeing this. from lchiang: my steps were not exactly the same since I didn't crash, but still it may be a key.

Jean-Francois mentioned he was looking into some of the forwarding bugs. Varada, can you help look into this, too?

I have narrowed this down. Branch (commercial) build 2002-06-24 does NOT have this problem on the messages I tried. Branch (commerical) build 2002-06-25 has the problem on the same messages I tried above. I haven't yet narrowed down how I get into this state. Some more observations: 1. Copied one of the messages that I had a problem with to a new folder on the same mail account. Able to forward that message in the new folder w/out any problems. 2. Tried some things with ducarroz. Recycle compose window doesn't have anything to do with this bug.

Here are the changes between that time: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_ 1_0_%280_%29%3FBRANCH&branchtype=regexp&dir=&file=&filetype=match&who=&whotype=m atch&hours=2&date=explicit&mindate=06%2F24%2F2002&maxdate=06%2F25%2F2002+04%3A00 &cvsroot=%2Fcvsroot&sortby=File

(I apologize for taking over this bug report. It may turn out that I may be running into a different cause for the bug even though the symptoms are the same as originally reported in this bug.)

restoring this bug to it's original state. New bug filed for my case: http://bugzilla.mozilla.org/show_bug.cgi?id=154734

is this still happening? is it only turbo related?

Previous reports list OS/2, Windows, Mac and Linux builds--isn't turbo only OS/2 and Windows? I've never (deliberately) run turbo mode on Linux, but I also haven't seen the error since April.

I have been unable to reproduce this bug. The last comment I made in this bug was that I thought it was related to the issue that if we have no accounts we cant have a compose window( and that bug was fixed). If someone can give test cases to reproduce this bug it would be helpful. I suggest keeping this bug open and on QA's radar.

I installed Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20020925 today to see if some other bug was fixed. That bug was but instead I have this one now which means I am completely unable to write any news or mail. Since the News/Mail part is the main reason I am using Mozilla it is of course a major issue to me. It essentially renders it useless to me, so I guess I'll switch back again.

I get this error in build 2002092506 for Win32 (using 98SE)??? [note: the title bar displays the build as 092506 but I actually downloaded and installed 092408-trunk - why the discrepancy? I completely removed any prior versions before installing]. I am using a single profile but have a number of SMTP accounts. I am completely unable to compose email (respond or compose) and this error is faithfully reproducible. I would try the 0925 build but there is a corruption in the browser.xpi archive (nightly/2002092508-trunk).

I get the same error message with build Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2b) Gecko/20020924.

Build 2002092608-trunk WFM. Should we close this bug as resolved by the nightly?

*** Bug 144585 has been marked as a duplicate of this bug. ***

Mac OS 9.1 Got the problem with 2002092508 Now WFM with 2002092708 Platform to All ?

I'm seeing this on macos x 10.2. Some time in the last few days I became unable to create a new message window with reply, reply-all, File->New->Message, or shift+apple+M. Instead of the new message window i get the infamous "error occurred while creating a new message compose window" dialog. Interestingly, I am never able to dismiss this dialog without first putting focus in some other window and then switching over to the dialog. I bet the 'unable to create a window' problem is some kind of focus problem too. The problem started while using the Sept 25 build. I exited and started up the oct 3 build and the problem continues.

taking all of varada's bugs.

Since installation of Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030114 under Windows 2000 prof 5.00.2195 SP2 I get the identical error message for all sorts of composing new mail messages (compose, forward inline or with attachment, reply, ...). The error message ends with: ".. Please try again. [". Before I updated regularly until Gecko/20030111 without having any problems when creating a new mail message. (Another problem dissappeared with 20030114: In attached mails the right mail header is now displayed, and not parts of the actual mail header.)

Confirmed - this has just started happening on my system after upgrading from 1.3 alpha to 2003011408. System: Windows 2000. Never had it before. Just one POP3 account configured in mailnews.

Bug 162640 is very similar and notes that the problem wasn't present in the previous day's build, 2003011308.

This has been resolved under bug 189011. It works again for me, using 2003011508.

I just installed Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030116 and for my environment this mail composition problem (see comment #43) disappeared. Thanks.

Using build 2003012522/Linux I get the error and the JavaScript dumps the following message [nsIMsgIdentity: id2],[nsIMsgIdentity: id3],[nsIMsgIdentity: id5],[nsIMsgIdentity: id4],[nsIMsgIdentity: id6] EX: = TypeError: result has no properties

This fixes the problem, but I'm not sure why the serverSupports.GetElementAt(0) is sometimes null.

Comment on attachment 112707 [details] [diff] [review] simple fix, v.0.1 reviews?

My fix is only for UI and it should be enough for many cases. (It is just one needed 'if' .) But there is still something weird. Somehow the mail.account.accountx.x -values are not always set right in the prefs.js. I changed manually those values and suddenly everything was ok again (even without my patch).

smaug's comments about his mail.account.accountx.x -values scares me. if we don't have an identity, what's going to happen on send? this patch might get rid of the exception, but will mail be sent? I'm more interested in figuring out how smaug (or others) got into this state. as far as the patch, we should probably handle this error differently, and act the same we act if you don't have any identities (bring up the new account wizard.)

I think we should use the patch, because it adds just one necessary if-check to the code, but it is not enough. (And the code in MsgComposeCommands.js should be cleaned anyway, too many dump-calls, wrong indentation etc.) Bringing up the new account wizard should happen (only) if there is not any correct identity. I'm not sure, but I believe that I got the prefs.js problems after removing one account. Some information about that account was left in the prefs.js.

looking into smaug's comments, I may have mis-understood his patch.

smaug, good catch on this one. to fill in the popup, we get all the identities, and then work our way back to the servers. note, this is why the list of identities doesn't match the order of accounts in the folder pane. for this bug, I think it might be possible to have identities without servers (but not by design, but it's not hard imagine how bugs in the past or exciting problems in the code could leave you like that.) I think we should fix this code to fill the identity popup from the list of accounts, in the same order as the folder pane.

jglick agrees about the order issue. let's fix these two issues (order and how-to-handle-identities-without-a-server) at the same time. working on a patch.

not working on a patch, but I hope neil can help out here. I will probably check in smaug's patch, but it would be removed when the real fix is in. here's how'd I'd fix this: when we fill in the identity picker in the compose window, we get all the identities from the account manager, go backwards to get the server for each one, and then create a menuitem and append it. Instead, we should be doing something like 1) getting all the accounts, and get the server for each account. 2) sort the servers to folder pane order 3) get the identities for each server (*) 4) create the menuitem and append it. (*) Keep in mind, not all servers have identities (think about "Local Folders"). See nsMsgAccountManagerDataSource::serverHasIdentities() for some sample code (in C++, but you'll be doing js). And, the nsIMsgAccount interface has readonly attribute nsISupportsArray identities; and attribute nsIMsgIdentity defaultIdentity; We should write the code to assume multiple identities will exist, but we don't currently support that. So use identities, and not defaultIdentity.

Comment on attachment 112878 [details] [diff] [review] fix based on smaug's fix, but we should fix the order issue, too. r=cavin.

Why try-catch when if-else should be enough?

smaug, this is really an unexpected error I'd like the code to reflect that. I'll log a new bug (on neil) about fixing FillIdentityListPopup() to populate the menulist in a different (and sorted way), and all this code will be removed.

spun off identity order bug to bug #191011

Comment on attachment 112903 [details] [diff] [review] diff, with more comments and notes carrying over cavin's r=, adding bienvenu's sr.

Comment on attachment 112903 [details] [diff] [review] diff, with more comments and notes a=asa (on behalf of drivers) for checkin to 1.3beta.

fixed. if smaug (or anyone else) knows how to reproduce the scenario where removing accounts leaves around identities, let's log a new bug for that.

account manager issue about "stale" prefs spun off to bug #195230