User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050814 MultiZilla/1.8.1.0j SeaMonkey/1.0a Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050814 MultiZilla/1.8.1.0j SeaMonkey/1.0a After running for a while, attempting to compose a new mail message fails - the mail window opens, but the address field is not editable, nor is the subject or message body. Checking the Javascript error log shows the following: Error: [JavaScript Error: "[Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgCompose.initEditor]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: InitEditor :: line 3193" data: no]" {file: "chrome://messenger/content/messengercompose/MsgComposeCommands.js" line: 3193}] Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 3193 Restarting Mozilla will clear the problem for a while. Reproducible: Sometimes Steps to Reproduce: 1. Start Seamonkey 2. File->New->Mail message - this will work. 3. Browse for some period of time 4. File->New->Mail message 5. If this works, goto step 3 Actual Results: After a period of browsing, the compose new mail feature will not work and the Javascript error above will be logged Expected Results: Mail should work. Javascript should NEVER throw an invalid pointer error. This may be due to my habit of using Multizilla group bookmarks to open many (> 10) tabs at the same time - perhaps there is some sort of race condition/resource locking that breaks when that many tabs are trying to render all at once.

I noticed this behavior with SM too. It seems not dependent from multizilla - created clean profile (mutizilla is installed into profile) and noticed the same. May be hard to reproduce, because happens not allways...

Related to Bug 300338? Please try a current trunkbuild newer than 09-01.

Are you sure about that bug number? At first glance it does not seem to have anything to do with this....

OK, I am seeing this with a build of 2005091201, as well.

Still seeing it in 2005100202 Error: [JavaScript Error: "[Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgCompose.initEditor]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: InitEditor :: line 3190" data: no]" {file: "chrome://messenger/content/messengercompose/MsgComposeCommands.js" line: 3190}] Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 3190

Also happens with Windows build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a The same JS Error, only with different line number: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgCompose.initEditor]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: InitEditor :: line 3200" data: no] Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 3200

I'm seeing this too with SM "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051124 SeaMonkey/1.0b". Haven't checked Javascript errors yet but compose window behaviour is just like in bug description.

The JS Error for me is just like in comment #6 when this bug occurs.

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

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

I get the same for any compose action with a current MOZILLA_1_8_0_BRANCH build sometimes: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgCompose.initEditor]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: InitEditor :: line 3200" data: no] Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 3200 Error: gMsgCompose.editor has no properties Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 191

I tend to run suite for weeks at a time and I have not been encountering this problem. Using trunk BuildID 2005112709 on WinXP SP2 at the moment.

Is this a problem with the recycled compose window? The next time it happens, retry the compose action immediately without closing the previous window. Note: I can't remember which window you then need to close first.

(In reply to comment #13) > Is this a problem with the recycled compose window? The next time it happens, > retry the compose action immediately without closing the previous window. > Note: I can't remember which window you then need to close first. This worked indeed. And first closing the new compose window and afterwards the broken one made it work again without an restart.

Does this happen with a clean profile (I assume it doesn't)? If not, can someone narrow down what pref is causing this or send their prefs.js to me? More consistent steps to reproduce would be nice too. If you just repeatedly invoke new mail composition and close the window, does it eventually show up?

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

> Does this happen with a clean profile (I assume it doesn't)? I guess comment 1 says it does. :) Adrius: were there any extensions installed to the app directory that would have been picked up by the clean profile? Did you have to do anything special with the clean profile to reproduce the bug (other than creating a dummy account)?

(In reply to comment #17) > > Does this happen with a clean profile (I assume it doesn't)? > > I guess comment 1 says it does. :) Yes, it does. I already did the test (some time, maybe about a week after writing my comment to this) - clean installation from zip file, new profile - no extensions, no old prefs; - and i could reproduce this bug after some time. > Adrius: were there any extensions installed to the app directory that would > have been picked up by the clean profile? Did you have to do anything special > with the clean profile to reproduce the bug (other than creating a dummy > account)? I think (correct me if i'm wrong)... If i get nightly zip file from mozilla.org, extract this to some/dir, run, create new profile, and use it - it can't pick any extensions, themes or prefs from my old account. Yes, my "work profile" is a bit overloaded - lots of extensions, non-standart theme, big prefs.js/user.js/UserChrome.css, etc. But i think new zipfile installation should not use them. Back to bug - i can reproduce it with SM beta (released in December); i'm pretty sure it should come up with current builds, because nobody fixed it ;-) But anyway, i can try to do the same with current nightly release - new directory with SM files, new profile, and try to reproduce it. For me it happens _only_ for newsgroups accounts, not for mail, but i do not reply to e-mails so often, this may be the problem. And newer saw this as "first reply" - i mean, this bug never comes up when i reply first time after starting up seamonkey. Error in JS console : Error: [JavaScript Error: "[Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgCompose.initEditor]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: InitEditor :: line 3200" data: no]" {file: "chrome://messenger/content/messengercompose/MsgComposeCommands.js" line: 3200}] Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 3200 More info with new install and clean profile - later. Thanks, and sorry for bad english.

Not blocking 1.0 or we'll never ship. I think we'd take a patch for 1.0.x though, if the fix seems safe.

So you are saying that a very reproducable bug, one which forces me to restart Mozilla on a VERY regular basis (as in, at least twice a day), is NOT a blocker for release?

Perhaps this bug is not common enough to warrant holding up the release, but note, I was so extremely frustrated by the constant freezing and necessary restarts, that for me Seamonkey is intolerable, and I wouldn't use it until this bug is fixed.

When I read comment #19, I immidiately thought of the old days of Netscape! Is this the way it really goes here? To ship a product with obvious, really annoying bugs is a roadway to loose users. I started to use Seamonkey because I like the Mozilla suite over the individual Firefox and Thunderbird programs. But I stopped using it the moment this bug kept occuring (couldn't send emails because of this). I will not switch back before this is fixed.

I dunno, it stopped happening to me after cleaning out my chrome folder. Have you all tried doing that? I guess the guiding consideration for CTho is how common this bug is that if very very few people encounter it, maybe it shouldn't block the release.

(In reply to comment #20) > So you are saying that a very reproducable bug, one which forces me to restart > Mozilla on a VERY regular basis (as in, at least twice a day), is NOT a blocker > for release? If you know, how to really reproduce it, tell us. Only because something is seen on a perhaps regular basis, doesn't mean it can be reproduced by a developer. We need steps, that exactly lead to this particular error. Without it's hard to fix, cause you can't test something that only occurs from time to time. Besides that, read comment #13 and #14. You don't have to restart SeaMonkey, you can work around with a few clicks.

Added a relnote for this and workaround from comment 13, setting keyword anyway.

as a more permanent workaround, shouldn't setting mail.compose.max_recycled_windows to 0 in about:config make the problem go away? Just did that here, and I'll report back in a few days/weeks if it came up again.

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

"More consistent steps to reproduce would be nice too. If you just repeatedly invoke new mail composition and close the window, does it eventually show up?" This hasn't been answered yet. I would like to know. I've tried that method anyway, and I can't reproduce this bug. I haven't ever seen it, since I rarely compose e-mail. I'm wondering what the habit of the reporters is. Do you leave the Mail & Newsgroups window open? It could be a factor.

(In reply to comment #28) > "More consistent steps to reproduce would be nice too. If you just repeatedly > invoke new mail composition and close the window, does it eventually show up?" No, I don't think so. > I'm wondering what the habit of the reporters is. Do you leave the Mail & > Newsgroups window open? It could be a factor. Yes, it is mostly open.

(In reply to comment #28) > I'm wondering what the habit of the reporters is. Do you leave the Mail & > Newsgroups window open? It could be a factor. Yes, Mail & Newsgropus window is open all day, mail is fetched from one imaps box every 10 minutes, Junk mail control enabled.

I also see this pretty often (maybe every third time I use Seamonkey 1.0 for some hours). The workaround as described by Neil in comment #13 works (in the window closing order mentioned in comment #14). Usually it only happened after composing 2-3 mails, this time it happened about 60-90 minutes after starting Seamonkey and only a few minutes after opening mailnews and fetching the mail from my pop server. No message composed before, just pressed reply to an existing message. I am using the adblock extension (v5 d3 nightly42), nothing else. I experience this problem since about December; this might or might not coincide with me starting to use adblock.

since disabling reuse (comment #26) I have not experienced this bug again.

1. I have adblock too. But I have been using it since a very long time and this issue has never occured with Mozilla 1.7.x or earlier. 2. The error message with line 3200 seems to occur only as second error, maybe after the real error has set the application into a wrong state. Why this? I got again a broken window on replying to a mail, had a look into the JavaScript Console and there it was not line 3200, but 821 IIRC. Unfortunately I cleared it before retrying it - but on the second try line 3200 was printed out again. Will be more careful next time ;) Workaround mentioned in comment #13 and comment #14 works.

This time it was fast, maybe I found a way to reproduce it on my system. Here at least the other error: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://communicator/content/sidebar/sidebarOverlay.js :: sidebar_open_default_panel :: line 821" data: no] Source File: chrome://communicator/content/sidebar/sidebarOverlay.js Line: 821 Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIControllers.removeController]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://navigator/content/navigator.js :: Shutdown :: line 788" data: no] Error: updateHomeButtonTooltip is not defined Source File: chrome://navigator/content/navigator.js Line: 135 Error: updateHomeButtonTooltip is not defined Source File: chrome://navigator/content/navigator.js Line: 135 Error: gBrowser is not defined Source File: chrome://navigator/content/navigator.js Line: 118 Error: document has no properties Source File: chrome://navigator/content/navigator.js Line: 97 Error: document has no properties Source File: chrome://navigator/content/navigator.js Line: 97 Error: document has no properties Source File: chrome://navigator/content/navigator.js Line: 97 Error: getBrowser is not defined Source File: chrome://navigator/content/navigator.js Line: 167 Error: Expected color but found 'default'. Error in parsing value for property 'border-color'. Declaration dropped. Source File: chrome://adblock/content/adblock.css Line: 33 Error: Expected color but found 'default'. Error in parsing value for property 'border-color'. Declaration dropped. Source File: chrome://adblock/content/adblock.css Line: 35 Error: Unknown namespace prefix 'html'. Ruleset ignored due to bad selector. Source File: chrome://messenger/skin/messageBody.css Line: 54 Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgCompose.initEditor]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: InitEditor :: line 3200" data: no] Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 3200

Ok, the other errors seem not to be related as they are already in the console immediately after start of SeaMonkey. But I have a procedure with which I can reproduce the error quite reliably at least on my system, but it's somewhat difficult: 1. Open SeaMonkey. 2. Open Bookmark Manager. 3. I have a tab group, from which I select 5 tabs: open in new tab. 4. It seems to be related to the AJAX-style links in the mid of the page ("OSCAR 2006 - DIE MATHEMATISCHE PROGNOSE" or "PARAMETER IN DER KATEGORIE "BESTER FILM"") at http://www.spiegel.de/wissenschaft/mensch/0,1518,400649,00.html, so click some of them. 5. Open Mail messenger. 6. Reply to a mail. 7. If it worked as normal with the first try, close the mail compose window and try 6. again. The error should have occured. If not close SeaMonkey completely and start again with 1.

(In reply to comment #32) > since disabling reuse (comment #26) I have not experienced this bug again. I still see this bug with mail.compose.max_recycled_windows set to 0.

(In reply to comment #35) unfortunately, i can't reproduce this with your steps

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

Please note my observation in bug 331551 - it happens mostly when you try to reply to HTML message in plaintext and cancell the composition right away. Workaround in commet 13 still works in these cases.

I just created a new mail composition window, pasted some text into it, and then closed the window (answering "no" when prompted whether I want to save the message). Following that, creating a new mail composition window invokes the previously closed window (i.e., the new composition window contains the same text that I had pasted into the previous composition window). So intuitively, it would certainly seem that a "recycling" of windows is occurring. I have the same error message in the Javascript console that others have reported. Prior to the aforementioned incident, the error happened when I tried to edit a saved draft. That was within several minutes of starting Mozilla, which seems to rule out a requirement of extended uptime to reproduce. Build string is as follows: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

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

What tracing options are available? I have to fix bugs all the time that I can't reproduce, just by putting lots of trace logging. Surely with the fairly explicit error messages already posted there's a good idea of the area.

Based on the line numbers, the line where it fails is http://lxr.mozilla.org/mozilla1.8/source/mailnews/compose/resources/content/MsgComposeCommands.js#3200 gMsgCompose.initEditor(editor, window.content); I'd guess failure is due to gMsgCompose = null. gMsgCompose should be initialized in ComposeStartup: http://lxr.mozilla.org/mozilla1.8/source/mailnews/compose/resources/content/MsgComposeCommands.js#1301 but you could add dump statements to the InitEditor method to verify my guess (or identify the real cause). The bigger question is how it gets into the bogus state.

I've been trying to figure out what causes this but I don't think there's anything in particular. It's probably just a race condition, IMHO. Whenever it happens I think about what I just did, but repeating that never leads to a reproduction of the bug. For example just now I copied an email address from a website by right-clicking the link and selecting "Copy email address". Compose - problem appears. Restarted, did the same thing from the same site, compose - no problem.

about to upgrade to seamonkey 1.0.2 and read the release note and saw this mentioned. Yes, I have unexperienced this regularly with 1.0.1 and I am glad to read about the work-around (comment 13). Hope it get fixed sometimes...

I use seamonkey 1.02, and have used every version of the suite since mozilla 1.4, and have never noticed this bug. Admittedly I don't compose many new messages, mostly replies to messages received. Also I don't have many extensions installed (generally just unclosetab). I run on ms-windows, using the french localisation. (Sometimes prelocalized, sometimes by adding to the original english version. I do tend to leave the mail open for long periods at a time, often for several days. However I have noticed a factor that may influence the problem. When different versions of mozilla are installed, even if using different profiles, there seems to be an interation between them. This is currently problematic between mozilla 1.7.12 and seamonkey 1.0.2. My seamonkey 1.0.1 was uninstalled before installing version 1.0.2 into an entirely different directory. In the registry, there were many references to the 1.0.1 installation, which was no longer present. When these were removed, and 1.0.2 uninstalled and reinstalled, many anomolies in the functioning of 1.0.2 disappeared. Interestingly, on installing newer versions into separate directories while the older versions are still installed, many elements of the older configuration are copied, including for example, all the entries in the plugins directory (including my text file notes). Another factor is that certain elements, such as the default profile, are stored in a common location, and are automatically updated with the installation of a newer version. All this adds up to a sort of interdependance between different versions of mozilla products installed, which means that this bug is not necessarily a bug of seamonkey itself, but could well be due to a corruption by another agent, such as an extension or a previous installation. It might help if the interdependance between the operating system and mozilla were minimized, and the interdependance between various mozilla modules installed were more controled.

(In reply to comment #46) > However I have noticed a factor that may influence the problem. When > different versions of mozilla are installed, even if using different > profiles, there > seems to be an interation between them. This is currently problematic > between mozilla 1.7.12 and seamonkey 1.0.2. > > My seamonkey 1.0.1 was uninstalled before installing version 1.0.2 into an > entirely different directory. This might be a problem with the GRE in %COMMONFILES%, that is put there during installation. NOT when using ZIP-Files instead of installers. Look under C:\Programsommon Files or similar, or type %COMMONFILES% into an explorer window. (I hope I remembered the exact name correctly)

(In reply to comment #47) > (In reply to comment #46) > > However I have noticed a factor that may influence the problem. When > > different versions of mozilla are installed, even if using different > > profiles, there > > seems to be an interation between them. This is currently problematic > > between mozilla 1.7.12 and seamonkey 1.0.2. > > > > My seamonkey 1.0.1 was uninstalled before installing version 1.0.2 into an > > entirely different directory. > > This might be a problem with the GRE in %COMMONFILES%, that is put there during > installation. NOT when using ZIP-Files instead of installers. > > Look under C:\Programsommon Files or similar, or type %COMMONFILES% into an > explorer window. (I hope I remembered the exact name correctly) > Forgive me for being such a newbee. I'm completely out of my element here and I'm not even sure if I'm in the right place. But, I just started having this same error today. I think I may be able to shed some light on your problem. I will list all the pertinent information I can think of and you can guide me in finding any I have missed. Unfortunately I don't know where to access the error messages so I can't paste any here. I have searched everywhere I can find and haven't located any logs. Application: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2 Home page is Bookmark Group of 7 tabs. This has only been the case for about 4 days now. Before that I used a single tab. Both browser and mail application are often left up, but usually closed at least twice daily. The error first occurred today. I closed mail application and the error was fixed for one email. Error occurred when attempting to compose the second. At which point restarting the mail client did not correct the problem. After reading this post I recreated the problem and used corrective measure in comment #13. This worked immediately. After completing this post I tried to compose another message and error occurred a third time. On the fourth try I repeated measure in #13 again and it worked, but this time I noticed that closing the good message did not produce a save or discard request but the bad message window did. Questions for you guys: What is the default directory location? I'm getting error messages when trying to open most of my files; see below This happens with all similar files, any clues? --------------------------- Java Virtual Machine Launcher --------------------------- Invalid or corrupt jarfile G:\Internet\Mozilla\chrome\local_install.jar --------------------------- OK --------------------------- Did I install the same version twice? see below. note* When I updated to version 1.0.2 I lost some mail folders-bug #340961. This should be one of these installations. But they appear to be the same. Start Log: 6/9/2006 - 10:00:02 AM System Info: OS Type: NT51 Major Version: 5 Minor Version: 1 Build Number: 2600 Extra String: Service Pack 2 Total Physical Memory: 522332KB Total Available Physical Memory: 180948KB Product Info: Install mode: Normal Company name: mozilla.org Product name (external): SeaMonkey Product name (internal): SeaMonkey Uninstall Filename: SeaMonkeyUninstall.exe UserAgent: 1.0.2 (en) Alternate search path: Components corrupted (startup): none Message Destination Path: Main: C:\Program Files\mozilla.org\SeaMonkey SubPath: Setup Type: C&omplete Components selected: Mozilla XPCOM GRE Navigator Mail & Newsgroups Spellchecker mozilla.org Uninstaller Chatzilla Debugger US English profile defaults English (US) language pack US region pack Inspector Roaming Website Reporter Components to download: Mozilla XPCOM found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ GRE found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ Navigator found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ Mail & Newsgroups found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ Spellchecker found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ mozilla.org Uninstaller found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ Chatzilla found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ Debugger found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ US English profile defaults found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ English (US) language pack found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ US region pack found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ Inspector found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ Roaming found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ Website Reporter found: C:\DOCUME~1\STACYS~1\LOCALS~1\Temp\ns_temp\ ** ** All components have been found locally. No components will be downloaded. ** Disk Space Info: Path: C:\ Required: 68399KB Available: 104905744KB Download protocol: HTTP Download status: ok Mozilla XPCOM: NetRetries:0, CRCRetries:0, NetTimeOuts:0 GRE: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Navigator: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Mail & Newsgroups: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Spellchecker: NetRetries:0, CRCRetries:0, NetTimeOuts:0 mozilla.org Uninstaller: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Chatzilla: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Debugger: NetRetries:0, CRCRetries:0, NetTimeOuts:0 US English profile defaults: NetRetries:0, CRCRetries:0, NetTimeOuts:0 English (US) language pack: NetRetries:0, CRCRetries:0, NetTimeOuts:0 US region pack: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Inspector: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Roaming: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Website Reporter: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Turbo Mode: true uncompressing GRE: 0 launching GRE Uncompressing Xpcom Succeeded: 0 XPInstall Start Navigator: 0 OK Mail & Newsgroups: 0 OK Spellchecker: 0 OK Chatzilla: 0 OK Debugger: 0 OK US English profile defaults: 0 OK English (US) language pack: 0 OK US region pack: 0 OK Inspector: 0 OK Roaming: 0 OK Website Reporter: 0 OK XPInstall End Launch Apps Start Launch Apps End End Log: 6/9/2006 - 10:00:41 AM Start Log: 6/22/2006 - 12:59:03 PM System Info: OS Type: NT51 Major Version: 5 Minor Version: 1 Build Number: 2600 Extra String: Service Pack 2 Total Physical Memory: 522336KB Total Available Physical Memory: 265556KB Product Info: Install mode: Normal Company name: mozilla.org Product name (external): SeaMonkey Product name (internal): SeaMonkey Uninstall Filename: SeaMonkeyUninstall.exe UserAgent: 1.0.2 (en) Alternate search path: Components corrupted (startup): none Message Destination Path: Main: g:\Internet SubPath: Setup Type: C&omplete Components selected: Mozilla XPCOM GRE Navigator Mail & Newsgroups Spellchecker mozilla.org Uninstaller Chatzilla Debugger US English profile defaults English (US) language pack US region pack Inspector Roaming Website Reporter Components to download: Mozilla XPCOM found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ GRE found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ Navigator found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ Mail & Newsgroups found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ Spellchecker found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ mozilla.org Uninstaller found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ Chatzilla found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ Debugger found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ US English profile defaults found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ English (US) language pack found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ US region pack found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ Inspector found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ Roaming found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ Website Reporter found: C:\DOCUME~1\Mom\LOCALS~1\Temp\ns_temp\ ** ** All components have been found locally. No components will be downloaded. ** Disk Space Info: Path: g:\ Required: 28992KB Available: 40881340KB Path: C:\ Required: 39407KB Available: 13539848KB Download protocol: HTTP Download status: ok Mozilla XPCOM: NetRetries:0, CRCRetries:0, NetTimeOuts:0 GRE: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Navigator: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Mail & Newsgroups: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Spellchecker: NetRetries:0, CRCRetries:0, NetTimeOuts:0 mozilla.org Uninstaller: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Chatzilla: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Debugger: NetRetries:0, CRCRetries:0, NetTimeOuts:0 US English profile defaults: NetRetries:0, CRCRetries:0, NetTimeOuts:0 English (US) language pack: NetRetries:0, CRCRetries:0, NetTimeOuts:0 US region pack: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Inspector: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Roaming: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Website Reporter: NetRetries:0, CRCRetries:0, NetTimeOuts:0 Turbo Mode: true uncompressing GRE: 0 launching GRE Uncompressing Xpcom Succeeded: 0 XPInstall Start Navigator: 0 OK Mail & Newsgroups: 0 OK Spellchecker: 0 OK Chatzilla: 0 OK Debugger: 0 OK US English profile defaults: 0 OK English (US) language pack: 0 OK US region pack: 0 OK Inspector: 0 OK Roaming: 0 OK Website Reporter: 0 OK XPInstall End Launch Apps Start Launch Apps End End Log: 6/22/2006 - 1:00:31 PM This error occurs when trying to view JScript Script files. --------------------------- Windows Script Host --------------------------- Script: G:\Internet\Mozilla\defaults\pref\browser-prefs.js Line: 44 Char: 1 Error: Object expected Code: 800A138F Source: Microsoft JScript runtime error --------------------------- OK --------------------------- I greatly appreciate any help you can give me, thanks.

I discovered the #13 work around totally by accident. After one or two tries, mail continued to work fine. Without the work around, closing mail did not help; had to close the browser also.

(In reply to comment #49) > I discovered the #13 work around totally by accident. After one or two tries, > mail continued to work fine. Without the work around, closing mail did not > help; had to close the browser also. > I had so much trouble I finally dumped seamonkey and went back to firefox. I tried reinstalling seamonkey but the notification bar at the bottom of the browser page is now 3 inches tall. I uninstalled it again and did a new install with the same resalts. Now my original default profile from seamonkey is inaccessable. When I try to use it I get an error message that states 'the default directory can not be located'. I'm so frustrated after wasting three entire days with this stupid thing. I really need to learn to code. I know my way around a computer but not inside. It's been 23 years since I learned basic.

This seems to happen the most for me when forwarding a message.

With all the discussion about this confirmed (yet seemingly unimportant to SeaMonkey devs) Mail/News bug, it surprises me that the cumbersome workaround described in Comment #13 (and in the release notes) is getting so much attention. Had anyone been paying attention to Morten Nilsen's Comment #26, they would've found an easier, more permanent fix for this annoying mail compose bug. Before upgrading multiple Mozilla 1.x and Netscape 7.x machines to SeaMonkey, I had to confirm that Morten's fix DOES work, and several tests of it confirmed that it DOES INDEED work for the 14 PCs I've upgraded. Devs: Modify the integer for mail.compose.max_recycled_windows in mailnews.js to ZERO, and mark this bug FIXED for the Win32 platform! Fixing (even temporarily) a MAJOR USABILITY BUG is well worth the cost of a tiny increase in compose window rendering speed.

i see the Problem mostly when I'm forwarding a message. When the Problem occurred me today i tested 10 times forwarding and every time this error occurred. Then i opened 2 forward windows at the same time (#13) and the second window opens right every time, the first not. Then i changed the pref (#26) and without a SeaMonkey restart i can open the forward window every time without any problems. So please, as long as no good fix is available, apply in SM 1.0.x and higher the workaround: mail.compose.max_recycled_windows to 0

(In reply to comment #53) > So please, as long as no good fix is available, apply in SM 1.0.x and higher > the workaround: mail.compose.max_recycled_windows to 0 > We don't know how many people this bug affects, but we do know that disabling the window recycling causes a pretty significant performance penalty, especially on older hardware.

(In reply to comment #54) > We don't know how many people this bug affects, but we do know that disabling > the window recycling causes a pretty significant performance penalty, > especially on older hardware. Well, we know it affects a LARGE number of users. Do you not read SeaMonkey forums, blogs and newsgroups? There are a HIGH number of users for which this bug affects usability. And it IS reproducible. The JS console tells one where to start looking for the fix. I tested SeaMonkey 1.0.2 on a Pentium 233MHz with 64MB RAM and Windows 98, and with window recycling disabled, there was NO very noticeable window draw lag, and the compose window was functional EVERY TIME. Switch on recycling, and the window is non-functional about half the time. It is rediculous that nobody is working on this high-profile bug that affects so many. Just keep a mention of it in the Release Notes. That'll fix it. Everyone who installs software always reads the Release Notes.

(In reply to comment #55) > (In reply to comment #54) > > > We don't know how many people this bug affects, but we do know that disabling > > the window recycling causes a pretty significant performance penalty, > > especially on older hardware. > > Well, we know it affects a LARGE number of users. Do you not read SeaMonkey > forums, blogs and newsgroups? There are a HIGH number of users for which this > bug affects usability. And it IS reproducible. The JS console tells one where > to start looking for the fix. ..and yet not a single developer or even user who has the ability to do debugging sees it? The JS console, as ajschult points out, shows us that a variable most likely ended up being null. It doesn't say how it got to be null. The bug is at the point where it became null, not where it got referenced. > It is rediculous that nobody is working on this high-profile bug that affects > so many. Just keep a mention of it in the Release Notes. That'll fix it. > Everyone who installs software always reads the Release Notes. Hey, I'm all for fixing it - give us steps to reproduce that actually work for us!

Plenty of tips for how to reproduce here, but it's just the usual problem that nobody wants to actually try. Not that I'm complaining, it's open source after all.

I'm guessing the debug stuff makes the stack/heap large enough that something isn't getting overwritten, thus making the bug ireproducible for developers.. it's a quite tough situation to get out of, but one thing that can be done, is disabling reuse per default, and add ui to turn it on under advanced prefs or something like that... It seems the main concern of speed isn't a big problem after all, as per comment #55

(In reply to comment #57) > Plenty of tips for how to reproduce here, but it's just the usual problem that > nobody wants to actually try. Not that I'm complaining, it's open source after > all. You don't think we tried to reproduce it? (In reply to comment #58) > I'm guessing the debug stuff makes the stack/heap large enough that something > isn't getting overwritten, thus making the bug ireproducible for developers.. I tested using the version of SeaMonkey 1.0 that shipped as the official release. I asked one of my friends (non-developer) to try for a while, and he also failed to reproduce it. > it's a quite tough situation to get out of, but one thing that can be done, is > disabling reuse per default, and add ui to turn it on under advanced prefs or > something like that... > > It seems the main concern of speed isn't a big problem after all, as per > comment #55 It takes multiple seconds for me for unrecycled windows vs. less than a second with it, and my hardware is 10x faster (literally) than a 233MHz Pentium. That makes me skeptical of comment 55.

In around 75% of my mail replying I can reproduce/see the problem. Running 1.0.3 at the moment it changed for me. Almost everytime I can edit the recipient fields but not the body area and the window is missing the original cited text. I'm a little involved in development but I'm not really sure how to debug this since it's partly in JS where I haven't a real idea. :-(

Here's a question: could this in some way be related to the speed of the mail server? That might explain why for some this is a very reproducible bug, and for others it is not. Could it be a race condition when a mail is sent, that depends upon how quickly the mail server accepts the message (thus how quickly the window is closed), that for some amount of delay from the mail server causes a race that leaves the window object in a bogus state, such that the next time the window is used, BOOM! To test my theory, perhaps code could be added for debug that would record the time for the mail server to respond, and those of us seeing the problem could report our times and the devs can compare that to their times?

It might be useless but just in case: Would not this sequence of errors help? Error: awGetPopupElement(top.MAX_RECIPIENTS) has no properties Source File: chrome://messenger/content/messengercompose/addressingWidgetOverlay.js Line: 551 Error: gMsgCompose.editor has no properties Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 191 and then the infamous Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgCompose.initEditor]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: InitEditor :: line 3200" data: no] Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 3200 closing and/or attempts of context editing generates in addition: Error: sMsgComposeService is not defined Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 1075 Error: editorElement.getEditor is not a function Source File: chrome://editor/content/ComposerCommands.js Line: 2341 Error: editorElement.getEditor is not a function Source File: chrome://editor/content/ComposerCommands.js Line: 2367

(In reply to comment #59) > I tested using the version of SeaMonkey 1.0 that shipped as the official > release. I asked one of my friends (non-developer) to try for a while, and he > also failed to reproduce it. I also failed to reproduce it when I tried at work, again with SeaMonkey 1.0, though I think it's a distro build rather than the official build (at work I use linux; at home I use XP Pro).

I can confirm being affected by this bug since SeaMonkey 1.0 (release Jan 2006), WinXP, Gecko/20060130.

I'm also affected with all Seamonkey Relese Builds, right now Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.6) Gecko/20060729 SeaMonkey/1.0.4 But this Bug already occured to my with the last Mozilla Suite Releases, AFAIR since 1.7.10. I created a new profile when migrating from Mozilla Suite to seamonkey. I just activated the reusage of the window to check what msg. i get. Right now when i reply / write a new Message it's: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgCompose.initEditor]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: InitEditor :: line 3200" data: no] Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 3200 After closing the window following error shows up: Error: gMsgCompose.editor has no properties Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 191 I hope this bug can be found & fixed soon. If you need more detailed error description, pls. tell me/us how to narrow it down.

> Based on the line numbers, the line where it fails is > http://lxr.mozilla.org/mozilla1.8/source/mailnews/compose/resources/content/MsgComposeCommands.js#3200 > gMsgCompose.initEditor(editor, window.content); > I'd guess failure is due to gMsgCompose = null. I don't think so. gMsgCompose being null should result in a "gMsgCompose has no properties" error, not an exception. But if you call gMsgCompose.initEditor with either parameter being null, you get that very error...

Looking at the code, InitEditor(...) is called only twice, and only the call at <http://lxr.mozilla.org/mozilla/source/mailnews/compose/resources/content/MsgComposeCommands.js#1393> can lead to |editor| being null. Supposing that window.content is not null, the method GetCurrentEditor() fails and might dump that to the system console (not the JS error console!), see <http://lxr.mozilla.org/mozilla/source/editor/ui/composer/content/editorUtilities.js#219>. So, those of you who can reproduce this regularly on a Linux system, please start SM from a shell (or with a shell attached) with the user_pref browser.dom.window.dump.enabled set to true and look out for leo messages there, too.

> look out for leo messages there, too. Erm, look out for _error_ messages there, too. :)

Worth reading ... about the cached compose windows as posted by gwtc in news://mozilla.support.seamonkey: http://www.mozilla.org/mailnews/arch/compose/cached.html (note: both unix bugs are fixed) https://bugzilla.mozilla.org/show_bug.cgi?id=104989#c26 hmm, did bug appear shortly after Bug 137698 landed? What is the signficance of Bruno 'Aqualon' Escherl's comment 36 "I still see this bug with mail.compose.max_recycled_windows set to 0"? (Bruno, you're still good?) Eyal in comment #23 > ... it stopped happening to me after cleaning out my chrome folder. Eyal, you made no other changes? And what exactly did you clean out? For linux, Karsten in comment 66 and comment 67 offers good advice. For windows, can someone supply a binary for ajschult's suggestion in comment 32? Marcus, Mirek, Wolfgang, Isaac, David, Adrian, wowbagger and all who have seen the bug - did anyone see this prior to 1.0a (noted in comment 0)? - has it ever gone away for any *significant* period of time? - does this occur just as frequently in a current trunk build? Adrian, can you still cause this 10/10 per comment 53?

> For windows, can someone supply a binary for ajschult's suggestion in comment 32? make that comment 43

> For linux, Karsten in comment 66 and comment 67 offers good advice. For > windows, can someone supply a binary for ajschult's suggestion in comment 32? Karsten's suggestion would work on any OS and would tell us the most important things that sprinkling dump statements everywhere would tell us.

(In reply to comment #69) > > Marcus, Mirek, Wolfgang, Isaac, David, Adrian, wowbagger and all who have seen > the bug > - did anyone see this prior to 1.0a (noted in comment 0)? I cannot recall whether the problem was prior 1.0a; although I have a feeling it was not present in Moz Suite 1.7, I do not want to mis-guide in this respect. It was long time ago and human memory is not the best recording device... > - has it ever gone away for any *significant* period of time? No, it was in all releases of SM I have used. > - does this occur just as frequently in a current trunk build? To be honest, I would rather say that there are days when I do not see it at all and days when it happens several times. I use three different machines with WinXP with slightly different installations and I see no statistical difference among these.

(In reply to comment #69) > - did anyone see this prior to 1.0a (noted in comment 0)? Never saw this on 1.7.x. Btw, i have one more comp. with moz 1.7, still working without glitches ;-) > - has it ever gone away for any *significant* period of time? No. It was in all SM releases. > - does this occur just as frequently in a current trunk build? Dunno with current, but ~3 weeks ago tested some builds - bug was there. About debugging : I'm pretty sure, that this bug is caused by some config keys or files left in profile. Done some tests... New install (clean OS), new SM profile, no addons, no themes, just simple config - didn't saw this bug for few days (sorry, it's unusable for me without addons, so no more tests). Back to my config - and i can reproduce this bug few times in a day without problems. If i remember correctly, i can get stuck windows even with clean profile on my existing setup (but very rarely, this makes my comment #1 useless), this may be caused by already existed plugins, R/O user.js or some other prefs... Someone from developers can provide steps to debug js? Add breakpoints, display values? I'm with moz from pre-1 times, and know basics. Bonus points - i can reproduce this bug without any problems several times/day ;-) Can i ask someone on irc to help me debug this?

> Someone from developers can provide steps to debug js? Providing the information for comment 67 would be a good start and doesn't require any modification or breakpoints, etc. Setting breakpoints is only going to be effective if you can actually make it fail on demand. You can stop by irc://moznet/seamonkey anytime. There is usually someone there that can help.

Mirek could have written my response. Every point is true for me too.

(In reply to comment #67) > So, those of you who can reproduce this regularly on a Linux system, please > start SM from a shell (or with a shell attached) with the user_pref > browser.dom.window.dump.enabled set to true and look out for leo messages > there, too. This was on a Win2k system. Console: Document http://www.hs.fi/uutiset/tuoreet/aikajarjestys/ loaded successfully ERROR: Cannot get the LDAP prefs service TypeError: gLDAPPrefsService.getService().gLDAPPrefsService has no properties TypeError: editorElement.getEditor is not a functionTypeError: editorElement.get Editor is not a functionTypeError: editorElement.getEditor is not a functionERRO R: Cannot get the LDAP prefs service TypeError: gLDAPPrefsService.getService().gLDAPPrefsService has no properties This is a recycled compose window! TypeError: editorElement.getEditor is not a function JS-console: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgCompose.initEditor]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: InitEditor :: line 3200" data: no] Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 3200 Fisrt stared message compose. Then closed that without typing anything. Then starting compose again and the bug showed up. SM 1.0.4.

> TypeError: editorElement.getEditor is not a function This means that editorElement is defined/not null, but hasn't a function named getEditor! Since this getEditor function is part of the XBL binding in editor.xml (http://landfill.mozilla.org/mxr-test/mozilla/source/xpfe/global/resources/content/bindings/editor.xml#40), this seems to be a race condition: we're calling a function before the XBL binding containing that function has been attached... The culprit is GetCurrentEditor() which breaks on an editor element without getEditor function (http://lxr.mozilla.org/mozilla/source/editor/ui/composer/content/editorUtilities.js#229). This leads to nsIMsgCompose.initEditor getting passed a null 'editor' parameter, provoking the infamous JS exception. I would just like to be able to see that bug myself to prove this analysis... :-/

Some more log from console when problem occurs. I closed the broken compose window and when promted to save, I selected save. This does not save anything but fixes the problem so that next attempt to compose succeeds. ERROR: Cannot get the LDAP prefs service TypeError: gLDAPPrefsService.getService().gLDAPPrefsService has no properties This is a recycled compose window! TypeError: editorElement.getEditor is not a functionSaveAsDraft from XUL GenericSendMessage from XUL Identity = [nsIMsgIdentity: id11] failed to SendMsg: TypeError: gMsgCompose.editor has no properties ComposeUnload from XUL ERROR: Cannot get the LDAP prefs service TypeError: gLDAPPrefsService.getService().gLDAPPrefsService has no properties

(In reply to comment #67) > Looking at the code, InitEditor(...) is called only twice, and only the call at > <http://lxr.mozilla.org/mozilla/source/mailnews/compose/resources/content/MsgComposeCommands.js#1393> > can lead to |editor| being null. Supposing that window.content is not null, the > method GetCurrentEditor() fails and might dump that to the system console (not > the JS error console!), see > <http://lxr.mozilla.org/mozilla/source/editor/ui/composer/content/editorUtilities.js#219>. > > So, those of you who can reproduce this regularly on a Linux system, please > start SM from a shell (or with a shell attached) with the user_pref > browser.dom.window.dump.enabled set to true and look out for leo messages > there, too. > I did this and for three weeks the problem never appeared. Was beginning to think it's a Heisenbug. Finally got it today. Here's the error output (Debian Etch/SM 1.0.4 release build): JS-Console: Error: gMsgCompose.editor has no properties Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 191 Console: TypeError: editorElement.getEditor is not a functionTypeError: editorElement.getEditor is not a functionTypeError: editorElement.getEditor is not a functionTypeError: editorElement.getEditor is not a functionTypeError: editorElement.getEditor is not a function

I found a new error and it appeared on the first try to reply to an email, so no compose window was recycled: FAILED TO START EDITOR: TypeError: editorElement.makeEditable is not a function INVALID EDITOR TYPE: undefined TypeError: commandManager has no propertiesINVALID EDITOR TYPE: undefined Failed to startup editor: TypeError: GetCurrentCommandManager() has no properties All tries afterwards gave the following known error: This is a recycled compose window! TypeError: editorElement.getEditor is not a function

Thanks Bruno. That's failing at http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mailnews/compose/resources/content/MsgComposeCommands.js&rev=1.385&mark=1334#1330 So, the non-recycled window is broken and then we recycle it. I guess there are more things to look at in the JS Debugger (like what this editorElement actually is since it's obviously not what we expect). If you stop by #seamonkey, we can help you out with Venkman.

Regarding this comment: ------- Comment #61 From David Hagood 2006-08-07 06:45 PST [reply] ------- Here's a question: could this in some way be related to the speed of the mail server? That might explain why for some this is a very reproducible bug, and for others it is not. Could it be a race condition when a mail is sent, that depends upon how quickly the mail server accepts the message (thus how quickly the window is closed), that for some amount of delay from the mail server causes a race that leaves the window object in a bogus state, such that the next time the window is used, BOOM! ================== I've observed exactly that problem in Mozilla (1.5 and earlier). If the server fails to respond within a few seconds, Moz spits back a bogus error about being unable to send mail. I saw it a lot when I first started using perfora.net (1&1) for email. A few months later they upgraded their server, and the problem went away.

I have some bad news: I'm using the workaround (setting mail.compose.max_recycled_windows to 0 in about:config) and its still occasionally happening to me ;(

(In reply to comment #83) > I have some bad news: I'm using the workaround (setting > mail.compose.max_recycled_windows to 0 in about:config) and its still > occasionally happening to me ;( Additionaly set mailnews.reuse_message_window to false. Changing only one option isn't working for ether.

Interesting information in bug 366482: there's an easily reproducible way to get the same compose window problem in Thunderbird, and a very similar problem in Seamonkey.

I have both mail.compose.max_recycled_windows = 0 and mailnews.reuse_message_window = false and it still happens occasionally. I guess those just make it show up a bit more.

Can someone check that bug 366775 (see attachment 251256 [details]) isn't the same thing? If it is, I'd like to close:dup that.

i get this window that error after auto updating firefox to the current build. firefox.exe- entry point not found the procedure entry point JS_SaveFrameChain could not be located in the dynamic link library js3250.dll. i dont know if this is the same error as the rest of you. i cant even run firefox now not even in safe mode. im running IE just to be able to post this so any help would be much apperatited on this. thx

This Bug still exists in Version 1.1.8, it seems that this only happens when you use SM for browsing. If using another browser, SM mail function seems to work like it should.