When Mozilla is launched without enough memory space, it starts saving 25 or so files named "test-1.xul", "test-2.xul", etc to the Desktop (default DL folder?). It can not compose a startup window, and what looks like a piece of toolbar switch accumulates at the top left corner of Desktop, then hang there. Since menu bar never gets displayed, you have to force quit the application. Correct behavior should be Mozilla stop launch process if there is not enough memory at startup.

asa - any idea where this goes? I'm baffeled (build config?)

hirata, please provide more information. What build were you testing? Branch or trunk? On what kind of machine were you testing it? How much memory? Does this happen if you launch mozilla mail or editor rather than mozilla browser (dragging the editor icon onto the mozilla icon in the mozilla directory, for example)? Unable to reproduce with 100908 mozilla trunk build on OS9

I have seen this in several recent trunk builds, including 2000100608. To get this happen, you should have only 18 to 20MB left as a free space. I usually have NS communicator etc running. I have tested this on iMac(333) with 96MB RAM Virtual memory OFF, and PB1400 48MB RAM with Virtual Memory ON, and got similar results. Mozilla is set to launch with at least 16MB of free space which is default. I will try Mail next time, as you suggested.

I tried with Mail as a startup , and the result was the same.: When I launched Mozilla with 18.1 MB of memory space left, Mozilla started to save test.xul files to Desktop after splash screen disappeared and a small piece of Toolbar appeared at the upper left corner of Desktop. It ended in type 2 crash this time. 2000100808 M18.

adding warren and hyatt. Maybe one of them can shed some light on thislow memory and xul issue.

reassigning to sfraser with the hopes that he know something about low mwmory stuff on mac.

My guess is that it's the disk cache that is barfing here. I can't see any place in the code where we create test-N.xul files.

FYI, only once in the past testing, I saw a "Save as" Dialog appearing during the storm of saving these files. The highest number of files I have got in the bug was something around 70. Do you want to see the content of the files? I think they are some genuine .xul files.

Yes, it would be good to see what is in those files to hopefully get a clue as to where these are coming from. Possibly just do a stuffit of the folder (preserving any subfolder hierarchy that might be there).

With today's build (2000102008), those .xul files came up as empty files. Nothing in them when opened from SimpleText, and their size was 0kb for every one of them. They used to contain style sheet-like text data in the past builds. Sorry, I did not keep them, but I have never seen subfolders. I have tried launching three times today, and in one instance, the file names were different; one "navigator.xul" and 29 "helperAppLauncher.xul" files showed up on the Desktop while Mozilla hanged right after its splash screen disappeared. The free memory space I had before launch was around 20 and 22 MB. I had Acrobat Reader, Windows Media Player (or Real Player), Claris Works, Simple Sound, TexEdit, and Sherlock open to get free space down from some 60 MB.

Yep. I got this to happen (loaded lots of applications, and pulled up windows in IE and Nav4 until they refused to open any more windows). Had largest unused block of 24MB, and started Mozilla. A tiny (~10px x ~20px) bit of chrome appeared in the screen and flickered. I got files [test-1.xul, test-2.xul ... test-64.xul] created in "Macintosh HD:TheVolumeSettingsFolder:". (macos 9.0.4 with 10/20 moz trunk build).

moving to mozilla0.9

This may be related to bug 42198. And if `A tiny (~10px x ~20px) bit of chrome appeared in the screen and flickered' was actually a lot of little windows appearing on top of each other, then that's what happened in bug 36928.

According to Emulator in n.p.m.mac, who tested NS6 releas recently, >I did notice that when I had "Save modules on > download", this problem popped up. When that option was unchecked, the problem was reportedly gone.

'save modules on download' is an installer option, and should have no impact on the performance of Netscape 6 once running. This problem this bug describes is a low memory issue, which can easily change from run to run.

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

The following is a comment from Michael Feldstein on 11/15/2000 at http://www.macintouch.com/netscape6.html. I downloaded and installed Netscape 6 yesterday. Unfortunately, when I try to run it, it covers my desktop with about 200 .xul files and then quits out. Needless to say, this does not make a good first impression.

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

Since my bug has been marked as a duplicate, here a screen shot of my desktop of a German MacOS 9.04. The files appear to have different names than in the neglish version.

The difference of the file names are due to the change in the way "save file" names the files being saved, which was implemented after this bug was filed.

Adding dependency, since this seems to be the only reproducible example in Bugzilla files that likely fixed by bug 42198 if it ever gets fixed.

This was a common complaint from NS6 Mac OS users, and should be addressed for beta1...

sfraser and I tried to get this to happen again on my machine (which I could do with an older build). Couldn't make this happen in a current build. Can anyone confirm that they still see this with a recent build? Thanks.

Yep, my G4 500 mhz with 256 megs of RAM has it about every 3-5 launches. I tried DiskAid (because I've had several instances where I've had to cold boot OS 9.0.4 instead of shutting down gracefully). I rebooted after repairing my file system with DiskAid and I'm still seeing it. The build was from 1-3-01

stephend's machine was showing this problem, and I spent some time tracking it down. This appears to be a component registration problem, which may result from installing over a previous installation. On stephend's mahine, the following extra DLLs were present in Components: libjar-1.shlb and in Essential Files: dom-1.shlb JavaScript-1.shlb libreg-1.shlb NSPR20-1.shlb NSRuntime-1.shlb NSStdLib-1.shlb xpcom-1.shlb zlib-1.shlb The problem happened every time reliably. If I removed the Component registry and let it autoregster, the problem went away.

Dan/Samir, can one of you dump the contents of that registry file, so we can see what's bad?

assigning to sdagley

OK, with lordpixel's help, we have more data on this now. It turns out to be related to the running-out-of FCBs bug, bug 64978. It happens that even with the patch in this bug, we can run out of FCBs when the chrome registry tries to open CSS files. I'll attach a log from a CreateInstance failure assertion, which shows that if nsChromeRegistry::LoadStyleSheetWithURL() fails to create a CSS loader, we run into this problem.

I know it's the same problem because I had lordpixel do a 'file 0' in MacsBug, which says: 256 fcb, 255 in use, inc 91 fonts not listed 1 free So perhaps we need to sprinkle SystemTask() dust around other file-opening places on startup? This is getting ugly. Alternatively, we find out why the OS is failing to grow the FCB table as it should.

Nominate for 0.9

Saw this again on stephend's machine today, on a Mozilla build. With some testing, I found the following: * Build history: he installed the 2/19 mozilla build over an older (date unknown) mozilla build. Mozilla was *not* running at the time. * There were *no* duplicate libs in either Essential Files or Components. * Trashing the compnents reg had no effect. * XUL file spewage occurred even after running a working copy of NS 6, so this isn't the FCBs problem. So we're back to square 1 on this. I have a copy of his build to test on.

Hrm, today's bustage is probably because the content DLL was not installed.

So this problem happens when, for some reason or other, we fail to create a content viewer for a docShell. The error is propagated back to nsDocumentOpenInfo::DispatchContent(), which falls back on downloading the content with a helper application (if possible). An easy way to reproduce this problem is to delete your content.dll before running. So the fix for this should be to have nsDocumentOpenInfo::DispatchContent() listen for specific errors returned by contentListener->DoContent(), and handle CreateInstance() failures differently from "i can't handle this content' errors. Reassigning to mscott for this.

marking nsbeta1-

arg! we have to fix this for 6.5. This is one of the Mac big-embarassment bugs. Spewing hundreds of XUL files over the user's desktop is not a nice thing to do.

what sfraser said (damn I type too slow :-)

Renominating for beta1. I don't think releasing a beta that didn't fix one of the top Mac complaints after six months is going to encourage too many people to try to final product.

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

->file handling, but retriage if needed.

ADT needs info, does this still happen?

Test: remove content.shlb from the components folder, and run Mozilla. This used to cause this bug.

If Simon's description of the cause of this problem is correct then this bug should have been fixed by Rick Pott's check in in Bug #96029 which was checked in back in August. In that code, nsDocumentOpenInfo::DispatchContent now kicks out if the call to nsURILoader::DispatchContent returns any kind of an error. Before it fell through to the save to disk code causing the helper app dialog to come up each time DispatchContent failed. That would have caused the behavior described in this bug and his fix would have cured that. The last work that happened on this bug was back in March of 2001, before Rick's fix in 96029. We'll have to see if we can reproduce this anymore, but I believe we are going to find that this is working now.

I have tested Simon's instruction in recent trunk builds. The result was hang in the splash screen, but no saving of xul files. Is the hang expected from the fix in bug 96029? I do not consider a hang a desirable outcome of good error detection.

Discussed at mail news bug meeting. Decided to minus this bug.

This bug is targeted at a Mac classic platform/OS, which is no longer supported by mozilla.org. Please re-target it to another platform/OS if this bug applies there as well or resolve this bug. I will resolve this bug as WONTFIX in four weeks if no action has been taken. To filter this and similar messages out, please filter for "mac_cla_reorg".

No longer an issue on OS X.