Closed Bug 162640 Opened 18 years ago Closed 17 years ago

an error occurred while creating a message compose window. Please try again. T


(MailNews Core :: Composition, defect)

Not set


(Not tracked)



(Reporter: randy, Assigned: mscott)



(Keywords: fixed1.4.1, regression)


(6 files)

Out of the blue I suddenly cannot send new mail messages or reply to mail I'm
receiving. I get this error:

an error occurred while creating a message compose window. Please try again. 

I did not install a new version recently (i am using 1.1), nor did I install any
other new software. Just let my machine running at work during the night and in
the morning I had a ms error that Mozilla made a booboo and that they shut it down.

First I tried reinstalling. No result. Then I tried removing everything mozilla
and then reinstalling. Also no result. Strange?

Could not find this bug listed yet... Only the same message but in a different
Assignee: ducarroz → varada
Are your mail accounts all there? 
Are you able to receive mail properly? 
Is there any difference when you send from one account as opposed to another?
Can you create new mail accounts and if so does the same problem happen there?
There was a known bug (that has been fixed now) about losing the prefs.js and
that could cause a lot of problems - can you see if this is the case(i.e. you
lost some of your prefs as well)
I did have multiple accounts and two of them 'forgot' their password. I removed
those after the described problem occurred to see if that would help. I added
one again, no problem there.

Yes I can receive mail, no problems, I just can't reply or compose. As for
sending from one account or another, I can't test that for I only have one
server I can use to send mail.

as for my prefs file, it was still there (one of the first things I checked) and
all my preferences seemed ok (except for those two passwords that is).
I'm getting this same completely out of the blue error message. I can also
receive mail just fine. The difference is that my error message says:

An error occurred while creating a message compose window. Please try again. 

(note the R instead of the T).
I observed this bug today in the build 20020924 on Sparc/Solaris. I can't
compose any message and I get the error message "An error occurred while
creating a message compose window. Please try again." (Without the T on the next
line.) I just installed a new version of Mozilla, but I left untouched my
settings and profile.
I solved this problem in my case by removing my mail accounts and manually
re-adding them..

Removing and readding accounts doesn't do it for me.

I forgot to specify that I'm running under Linux, build 2002092421. I've tried
running it under root in addition to my normal user account, with no dice.

I suppose it's just a hopefully temporal nightly problem.
Seems fixed with build 2002092511
Same error using latest W2k build. Have un/re-installed.  Have crested new profile and rebuilt maile accounts.  All three accounts respond with same error.
I'm seeing this behavior with the latest nightly, 2003011405.  Whenever I try to
open a message composer window, either by replying, forwarding, or trying to
compose a new message, I get the error:

"An error occurred while creating a message compose window.  Please try again.\n["
Build 2003011408 gives me the same behavior.
I am also seeing this on Mac OS X, Mozilla 2003011408. 

In my case, creating a new profile and immediately creating a mail message works
(prior to setting up mail accounts; this also prompts the setup wizard). As soon
as I configure my mail account (using IMAP, but I have not tried POP) I get the
error message.

Moreover the alert box has no focus and clicking on it does not bring it into
focus so you cannot dismiss it. Switching to another window or application and
then switching to the alert box will bring it into focus (during that time there
is a "compose" item listed under the window menu along with an item with no
name. Choosing the compose item brings the alert into focus. 
This does NOT happen in 2003011308 on Mac OS X.
same troubles with:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030114
I can reproduce the problem with a new user (and a new account)
Looks like 20030114 had this problem temporarily
2003011505 is fine.
It's happening here with:
Mozilla 1.3b Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.3b) Gecko/20030114
and it's running on:
bash-2.05$ uname -a
SunOS assdebuger 5.8 Generic_108529-11 i86pc i386 i86pc

Can't create a new mail and can't post to a newsgroup.
Is this a duplicate of the bug 131384?
This doesn't seem to be depdendant on the prefs. I tried copying a prefs.js file
of a fresh new profile, and then creating a mail account thru the wizard.
Afterwards, I can open a Compose window -- UNTIL I RESTART MOZILLA - then the
problem returns.

The new profile I created doesn't have the problem.

Can the Mozilla developers add some more clues to this error message? As it is
now, it's totally unclear -- is it something in the RDF files? Something in the
component cache?
I am having the exact same problem with the 1.3b so it appears that this problem
i still around. I am using the RH8 RPMS with gtk2/xft
I had this problem using 2003022508 build.
Then I switch back to 2003022408 build (rename 0225 build folder and change my
0204 folder back)  the problem does not appear.
This has just started happening to me on 1.4a
I'm taking the liberty of confirming this.
The error message is generated when an exception is caught at line 1380 of
mozilla/mailnews/compose/resources/content/MsgComposeCommands.js, but I have no
idea how to debug this. Can someone give me a clue? How do I see the output
generated by the dump function at line 1381?
Ever confirmed: true
Same here, build 2003022408 works fine, the latest builds don't. This
is a blocker for me, since I am no longer able to write or reply 
to emails.

I am using multiple identities, maybe this is the cause?
The fix for bug 195085 seems to have triggered this bug for me. If I back out
the changes to mailnews/compose/resources/content/MsgComposeCommands.js, the
problem disappears.
Depends on: 195085
OS: Windows XP → All
This started for me also with 20030301, since then I have tried deleting the folder and re-installing, with no result.

I am running winxp/amd/512mb, 4GB free on C drive
Same problem here with build 2003031714 winXP

It worked perfectly yesterday and I didn't change anything in my profile. The
only unusual thing related to mail I did yesterday was deleting a news server
account I no longer use.

My prefs.js is still there, I tried deleting chrome directory, xul.mfl,
panacea.dat all rdf files in my profile as well as registry.dat without any
success. I use multiple pop accounts and my SMTP hasn't changed. I can receive
my pop mail without any problem. This is really weird :-( I also
uninstalled/reinstalled the build without success. I tried with a new profile
and it works.
Ok, I fixed the problem. the suppression of the newsgroup account yesterday did
not suppress the account in the prefs.js file and caused the problem.

It seems similar to the problem in bug 131384 (actually, this bug gave me the
idea of checking all references to accounts)
WFM after editing pref.js by hand - removed a superfluous account.
Installed moz 1.4a and received this error on any message create.  After
tracking down this bug entry, manually edited prefs.js, finally figured out
what was wrong (a mail.account.accountX entry referring to a non-existant
mail.server.serverY and a truncated mail.identity.idZ), removed the data, and
things worked.

However, this would be very bad if a non-tech ran into this (and some non-techs
are using Mozilla).  IMO, there needs to be a mechanism to parse the prefs.js
for nonsense entries and comment them out.  If I had C++ experience, I would
code it myself, but I don't (nor a compiler, but that can be fixed by getting
I'm seeing the same error message when I try to compose a mail message. It
doesn't matter what method I use to try to compose a message (keyboard shortcut,
web link, button). I have two accounts, one pop, one imap. I'm running Linux
Mandrake 9.0 (and recently upgraded to 9.1; same problem). I was running 1.4a,
problem goes away if I load 1.3 (no change in configuration). I receive email
without problems.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507
Reproducable: Always

I ran into this problem today simply installing 1.4 beta into a new directory
not changing anything.
I use multiple mail accounts and IMAP; also I'm still able to get messages.
It doesn't matter what method I use to try to compose a message (keyboard
shortcut, web link, button).

I'm a non-tech :-( - so I now try to install 1.3.1 to fix.
An complete de- and re-installation of Mozilla 1.4 beta, including an manual delete of the folder, solved the problem for me.

I guess it was caused by copying files from the Mozilla 1.4 alpha-folder to the (new) folder of Mozilla 1.4 beta. So by now I recommend to "re-install" all plugins, skins etc. by their original files (saved on the harddisk) and to do NOT simply copy them from the old folders.
After installing 1.4a to 1.4b ( 2003050714 ) i had te same problem, could not compose a new e-mail. or edit a e-mail as new. Hope there will be a more easy solution.. hate to reinstall my whole Mozilla again.
I installed Mozilla 1.4 RC1 Build ID: 2003052908 last night, and this morning I
tried to send an email and I'm getting this error message.   I installed over
Mozilla 1.3
Do not install "over" previous versions of mozilla.
Uninstall the old version, and make sure the directory that mozilla was
installed to has been removed.
I've been getting this since 1.4 beta. I'm dead in the water with all my mail,
can't send a single one. This is the worse showstopper bug in Mozilla since 1.0
(at least for me). Could someone explain clearly how prefs.js needs to be fixed? 
Just started getting this same error dialog after upgrading to mozilla-win32-1.4b on a fully patched up Win98SE machine. Multiple accounts used, will try cleaning prefs.js.
This is the prefs file from a Mozilla account using win32-1.4b on WIndows 98
SE, fully patched. It will not allow the creation of a Compose window, showing
the same dialog mentioned above.
The original reporter had a profile corruption issue due to a crash.  Nearly
every comment since then has described a problem due to installing a new version
of Mozilla over top of an existing installation.   That is bug 200419 , not this

Resolving as WFM, since the reporter is not having this problem anymore.
Closed: 17 years ago
Resolution: --- → WORKSFORME
I can't believe a crucial bug like this get swept under the table. if Mozilla
wants to make it anywhere, any time it's supposed to handle the case of users
upgrading to new versions without corrupting their setups. This solution (or
lack of it) sucks, plain and simple, I'm appalled this is the response of the
Mozilla the meantime I still can't send a single piece of email from
Mozilla...and I presume I am expected to redo the setups for all the 8 different
email accounts I have setup all over again, etc, etc...?'s not does not work for me...and I'm appalled you do
not seem to be interested in fixing the worst bug in Mail & News since 2-3 years
(yes, I've been using Mozilla since the pre-1.0 days).

And this has nothing to do with bug Mozilla 1.4a never crashed
during install and I still have this issue! So how come it has anything to do
with 200419?

I mean bug 200651
The bug linked to in my previous comment was a typo.
Comment #40, I had this problem with 1.4a and 1.4b, so I re-installed 1.3 both
times.  But when 1.4rc1 came out, I took the not pleasant task of deleting the
mail-related settings from prefs.js and then re-setting up my e-mail and
newsgroup accounts.

This is a problem with upgrading.  I always uninstall previous versions and
delete everything in the program folder except for plug-ins and my splash
screen.  This is indeed a real issue, not user incompetence.

Comment #41, you are right.  I mean, we can't expect Mozilla to always behave,
being that it's for testers.  But the thing that concerns me is that this bug is
going unfixed and 1.4 is going to become the stable branch, meaning that
Netscape users that upgrade to the 1.4-based version are likely going to have
this problem too.  Netscape is supposed to be for end-users but, in my opinion,
this bug is just too much of a blocker for anyone other than us testers to
contend with.
I think the view from the floor is "Fix it" and I can't help but agree I'm afraid.

If it is a case of prioritising work, how about we look at the impact to user of
this fault. They upgrade the thing and it stops them sending mail. Bit of a show
stopper for a mail client I'd say.

I'm not really sure that suggesting that we should dump all our setting and
start from scratch is really a runner either.

I understand that this is a beta version and therefore a bit ragged at times,
but the idea of a beta is to be grooming it for the general user. Well the
general user sure ain't going to like this one.

How does one get a bug reopened around here. It may have a workaround, and a
rather untidy one at that, but that isn't resolved it's relieved at best.
Go nuts
Resolution: WORKSFORME → ---
" ... But the thing that concerns me is that this bug is
going unfixed and 1.4 is going to become the stable branch, meaning that
Netscape users that upgrade to the 1.4-based version are likely going to have
this problem too.  Netscape is supposed to be for end-users but, in my opinion,
this bug is just too much of a blocker for anyone other than us testers to
contend with."

That's it in fact. And then at worst case we have a new Netscape 6.0 which is
rather unusable ;) 
Just my 2 cents BEING an kind of a "normal" end-user...
Flags: blocking1.5a+
Flags: blocking1.4.x+
this is a big-big problem, 'cause i cannot compose any mail with 1.4 final version.
when will this bug fixed?
skerl: you cannot set (+) blocking flags, only request them (?).
Flags: blocking1.5a+
Flags: blocking1.4.x+
Ok, so I'm requesting the blocking flags. The email client
is totally useless for me and a lot of other people. 
Since more than a month I'm not able to send any email. 
I cannot understand, that a bug that blocks a lot of users
from sending emails, isn't a blocking bug. 
Please don't force me to switch to Outlook!
Flags: blocking1.5a?
Flags: blocking1.4.x?
Composing email in 1.4 final was working fine until just now. I fixed the bug by
downgrading to 1.3.  This is the second time I've downgraded.  I had this
problem in one of the RC builds, and I thought it was fixed, but I was wrong.  I
generally compose email by clicking the "compose" button in the mail client. 
Just now, for the first time since I've installed 1.4 final, I clicked on an "A"
tag with a mailto: url, and then the bug appeared, then immediatly trying to
click on the compose button in the mail client, the same error occurs.  That's
all I can think of that I've done differently lately.
No problems with 1.3.1 on my 98 machine or my xp-pro I8200.
Loaded 1.4 final on my 98 machine and it works fine.
Loaded it on my xp laptop (new directory)  and I get the
"error occurred while creating a message compose window"
message. Did multiple remove and reinstalls - no luck.
Put 1.3.1 back on the xp machine.
Hi all

it observed the sabe havior, upgraded from mozilla-1.3-r2 to 1.4 at gentoo. 
Do I really have to reset and d/l all my few GB mailboxes???


*** Bug 212085 has been marked as a duplicate of this bug. ***
Considering this bug in 1.4 (Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4)
Gecko/20030624) creating a new profile helped (even with the overwriting
However I would also tend to marking this bug as a blocker.
well, varada ain't going to fix it, that's for sure.

the theory (at least in bugs #195230 and bug #195085) was that bad prefs
(account settings) lead to this problem.

the fix for bug #195085 should have addressed this, but sounds like there is
still a problem.
Assignee: varada → sspitzer
not a blocker, but I need to figure out what state (of account settings, in
prefs) is leading to this, so I can make the compose js (or C++) more robust.
Marking as "not a blocker" (comment 56).  We've shipped with this before, and
while it's serious, we're not going to hold the release for it.
Flags: blocking1.5a? → blocking1.5a-
Wow, what an altitude..
I mean, an email client that cannot send emails...
What’s next, loosing browsing ability in the browser?
Best statement of all is: we had this bug in a
shipped release so we don’t need to fix this for
the next release. Being a software developer, I should
told my boss that we don’t need to fix *shipped*
bugs. We could save a lot of money and time...
But the question that remains using this point of
view is: do we ever need to fix *any* bug in the
Astonishing - We've shipped with this before, so we can do so again?

And how many potential users are you going to lose each time?

You'll either risk creating an island of users sticking with 1.3 or get a
percentage migrating back to outlook.

Personally, I spent about 4 hours figuring out the prefs settings, isolating
this to the area of account prefs, then creating a new profile and manually move
across all the settings and accounts I wanted to keep.  If I was non-technical I
would only have the choice to stick with 1.3 or go back to another mail client.
 Each time this happens a user is less likely to risk trying future versions,
just in case he finds he can't migrate back to 1.3

Given that these faulty settings were working in 1.3, (however damaged or
irrational they might appear), at the very least a new profile, copy and
sanitisation should be offered at install.

If I was using the nightly builds I'd understand the point of view to live with
it - when it has occured through using the "public" releases

When it is not a bug that can be harvested via talkback, and bugzilla is not
exactly friendly for non-techies, one wonders how many people silently met this
bug, decided Mozilla was useless and went elsewhere.  As others have said a mail
client being able to send mail is fairly fundamental after all.
Flags: blocking1.5a- → blocking1.5a?
Time to install a validating parser on all these prefs?

XML suuure is nice for that kind of structured data...  I'm a little frustrated 
with js anyhow.

Maybe we could break prefs into multiple XML files so any corruption or 
inconsistencies could be localized to a subset of prefs and replaced with best 
guess or backup documents?
still occurs with Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5b) Gecko/20030717
For those of us who are stuck dead in the water...could someone finally
post a step-by-step guide to manually cleaning up the prefs.js file, so that
Mozilla Mail is usable again?

I've tried deleting stuff in it myself, but alas the error still is happening...
type about:config into the URL box, then scroll down to the mail.* settings -
you'll find all the settings changed from default values are in bold.

In my case I managed to pin it down to some sort of inconsistencies in


I haven't spent much time looking at what was wrong, but there were far too many
of them - I have three servers set up and local folders, yet there were entries
for 1 through 16.  Moz 1.3 was quite happy with whatever mess it was in, which
is the irritating thing.  Once I had imported across to a new profile I had four
sets of entries in sensible order.  1.3 only showed 4 sets of data in mail
account preferences window, yet underlying this was much messier.  It should
therefore be possible to automate the cleanup.

Profile settings - Reinstalling with a new profile and a little messing around
and I'm back running with all my important settings.  You'll find is an excellent help in this regard, for
instance telling you which files your passwords are saved to.  The only bit that
was a pain was switching back and forth between profiles on a trial and error
basis, manually creating the e-mail accounts in the new profiles, quit mozilla,
copy in the mail files, restart.

Hopefully this gives you something to go on - if you're going down this route

I've attached a file with the relevant broken settings from my own system.
*** Bug 213259 has been marked as a duplicate of this bug. ***
This is a minimalist list of prefs from Matt's prefs file:
user_pref("mail.account.account1.identities", "id1");
user_pref("mail.account.account1.server", "server1");
user_pref("mail.account.account2.identities", "id2");
user_pref("mail.accountmanager.accounts", "account1,account2");
user_pref("mail.server.server1.hostname", "");
user_pref("mail.server.server1.type", "nntp");

The problem is that account4 exists, but has no server.  In Matt's original
prefs,  server4-9 did not exist, but were referenced in accounts4-9.  This seems
to be the same thing as Brendt (comment 29).  Andrew Meredith might have a
different problem...
Attached patch patchSplinter Review
this fixes the minimalist pref list as well as Matt's full-blown prefs.
I was able to open compose with Andrew Meredith's prefs even without this
Attachment #128134 - Flags: review?(sspitzer)
this is a regression from bug 191011
Keywords: regression
I had this problem starting with 1.4 final too. 
After cleaning up mail.account.account*.*, mail.accountmanager.accounts with no
longer existing server* and id* entries in prefs.js it worked for me again.
But this is a highly annoying bug and should be a showstopper! Very bad!
mozilla1.5a released. unsetting blocking request.
Flags: blocking1.5a?
I hope that someone is sane enough to set the blocking flag for 1.5b
I’m afraid I already know the answer: the bug was in 1.5a so we don’t
need to fix it for 1.5b.... 
Flags: blocking1.5b?
we should try for 1.5b... if there is any possible way for folks to help out in
debugging or isolating this problem that would really help...
Flags: blocking1.5b? → blocking1.5b+
> if there is any possible way for folks to help out in debugging or isolating 
> this problem that would really help...

the problem is already debugged and isolated.
review-love is the missing ingredient
what identity is chosen for the message if we run this new patch which falls out
of Fill In Idnetity if the server entry in prefs is bogus?
Comment on attachment 128134 [details] [diff] [review]

mscott, this function is to fill in the From: drop-down; the previous code
required a server for each identity but used try/catch so ignoring corrupt
accounts... the current code does no checking, so if a corrupt account has no
server (even Local Folders has a server with no identities) then it fails...
nothing here affects the preselected identity. (r=me if you want it.)
Thanks Neil. Let's treat this as


I can check this in.
Assignee: sspitzer → scott
fixed for thunderbird and seamonkey mail.
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Attachment #128134 - Flags: review?(sspitzer)
Comment on attachment 128134 [details] [diff] [review]

this patch fixes a bug that prevents people from composing mail (through no
fault of their own)
virtually no risk.
Attachment #128134 - Flags: approval1.4.x?
Comment on attachment 128134 [details] [diff] [review]

Attachment #128134 - Flags: approval1.4.x? → approval1.4.x+
Please add fixed1.4.1 keyword when checked in.
Flags: blocking1.4.x? → blocking1.4.x+
Keywords: fixed1.4.1
*** Bug 217869 has been marked as a duplicate of this bug. ***
Blocks: 224532
I use thunderbird 0.6 and i got the famous "an error occurred while creating a
message compose window".
This is my first use of thunderbird. I've checked the prefs.js file for
consistency. I've also recreated the profile. But i still got this message when
trying to compose a message.
A mail application that can't send message is not useful ...

Product: MailNews → Core
(In reply to comment #29)
> Created an attachment (id=121256) [edit]
> subset of bad prefs.js, with bad info
> Installed moz 1.4a and received this error on any message create.  After
> tracking down this bug entry, manually edited prefs.js, finally figured out
> what was wrong (a mail.account.accountX entry referring to a non-existant
> mail.server.serverY and a truncated mail.identity.idZ), removed the data, and
> things worked.

I got rid of old accounts. ids, and servers, and it still doesn't work!
1. What does "remove the data" mean?
2. Does the Local Account need an id?
3. I don't have an account1, and thunderbird keeps trying to create a reference
to account1 in mail.accountmanager.account!

I renamed my last account, account8, to account1 globally,  I also did global
replacements to make sure I had contiguous "account"s, "id"s, and "server"s in
prefs.js.  (I.e., the numbering of these went from 1 to n (by 1) with no missing

Now thunderbird is mostly happy.  If I double-click on a message in my main
drafts folder, the message doesn't open up in an edit window, as it's supposed
to do. (a) If I right-click the message and select "Edit as new...", then I can
edit.  (b) If I double-click a template in my Local Folder, then the message is
copied to an edit window.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.