I just installed Mozilla 0.9.2 on my Dell Laptop, Pentium III, SuSE Linux 7.0, 2.4.5 kernel, XFree86 4.0.3, Gnome, sawfish. Worked fine. Then I installed the JRE 1.3 plug-in, and got "Installation successful". I exited Mozilla. When I restarted, I got a message that some part of Mozilla was still running, so I rebooted. Now when I start Mozilla, I get the "Select user profile" window as usual, and the I am inside the initialize Hey : You are in QFA Startup (QFA)Talkback loaded Ok. ...and then nothing. I found the release note about putting a link in my mozilla0.9.2/plugins directory for libjavaplugin_oji.so. That seems to apply to a previous version of mozilla, because the link was already there when I looked. Note that the Release Notes says "libjava.oji.so directory", which I think should say "libjavaplugin_oji.so file". Anyway I tried renaming the link to something meaningless, to make mozilla ignore the Java plugin and start working again, but no luck: it just hangs. This is quite reproducible: I can't run mozilla at all now. Is there a command-line argument I can use to produce verbose debugging to give you more information than this?

thisis probably the profile manager issue where you cannot start with an old profile or something..i do not know the bug number.. ccing the qa

I believe you are beyond profiles here. I think the console lines before what is included here are what profile passed in etc. ccing dbragg for insights on the first message - remove xpicleanup.dat?

I'd need to see the actual text of the "mozilla is running" message. Was it more like, "Mozilla needs to shutdown to allow a previous installation to finish"? Are you getting absolutely nothing when you start mozilla or are you getting a message dialog everytime?

Seeing this on the commercial builds as well. If you install the commercial build with custom or full install method and include the Java Plugin, this hangs the browser on initial startup. Changing severity to critical and adding nsbranch keyword. Confirming bug. The last known set of builds that worked was the July02 builds. Trying to trace down what changed between July 02 and July 03.

shannon, i believed you mentioned that you are seeing this on HPUX. adding you to Cc.

Is this a plugin issue or an installer issue? What happens if one manually installs the Java plugin?

Peter, I installed the plugin from http://home.netscape.com/plugins/jvm.html and the browser started with no problems (using one single profile). I see the problem if I do a clean installation of the commercial and trunk bits on my linux system (clean meaning I delete my .mozilla directory). If I install todays bits (2001070510) with the "Recommended" option, browser starts up fine. If choose a full or custom, and specifically choose to install the JVM plugin with no .mozilla directory on home directory, will reproduce this hang. From what the reporter stated, he had multiple profiles in his .mozilla directory. After I installed the Java Plugin with multiple profiles in my .mozilla directory, and attempted to restart the browser I can reproduce the hang. So the issue happens in both cases...after plugin install (assuming multiple profiles) and during initial browser install (with no profiles existing on the system).

see bug 89188, sounds similar

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

Cancel the comment about the july 02 builds working. Just checked my build, and I installed it without the java plugin (thus multi-profiles work). I've been seeing variations of this hang for a while (see bug 897843, and bugscape-bug 5992), hopefully this is narrowed down to the java plugin installation.

reassign : dbragg?

Uh, No one has verified that this is a java "installation" issue and not just a java problem that I can see. Does anyone know what the java installer is putting on the system? Sounds like the java installer (a Sun product as far as I know) is putting things on the system that break Mozilla.

I don't know exactly who wrote the java installer or what it's SUPPOSED to be doing but install issues are supposed to go to Syd. reassigning.

adding bug this blocks Syd, See bug 88893 - N6 does not launch when using profile manager - with FULL setup type build. I confirmed by doing all my regular Profile and Activation tests with a recommended setup type. Then I added Java to the recommended installation and am unable to launch- even with profiles created in first set of tests. I can also reproduce the problem with a FULL setup type install etc

see bug 5016- java installs ok on commercial trunk

Yeah but that was closed on 5/23. It seems like this has broken since then. Can someone verify it's working on latest commercial branch/trunk?

Found a simple work-around! The comments about different results depending on the existence of multiple profiles made me try deleting the "default" profile, leaving only my own profile. This fixed the problem. Thanks again! I'm a bugzilla newbie, so I don't know the "proper" disposition of this bug. I suppose it should have a lower priority, and be marked "work-around exists". BTW, when the bug was alive, another "fix" was to run mozilla as root. Thanks to all for the help! Now if I can just figure out how to make mozilla stop using massively ugly fonts...

This is NOT working on the 2001070604 branch build for either K'Trina or me Once I install Java whether by FULL setup type install, or by RECOMMENDED and add Java using the plugin, I cannot launch N6 Marking blocker - if you want to use Java, you cannot launch with a new or migrated profile- not sure about old profile but will test

Lisa, Wanted you to be aware of this going into PDT today.

PDT+. We need to fully understand what's going on here. Adding a Sun person to the CC list...

Reporter: Can you use other plugins other than Java Plugin such as flash media player?

Is there any eta that can be added to the status whiteboard?

Manually installing the flash player files ShockwaveFlash.class and libflashplayer.so files in the plugins directory works fine using todays branch builds. Installed on single profile, and multiprofile environment. The Java plugin looks like the only plugin that results in a hang for multi-profiles and initial install (install w/out .mozilla directory and migrate a 4.x profile).

I did a custom install - deselected Java, select Flash Player and profiles acted as expected, app launched as expected

Looking

Adding eng. mgr. of Java Plug-In group; don't know if this is relevant to him, though.

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

verified failure/success scenarios. Here are the files we install (did a diff of the directory contents). Can someone verify there is nothing missing?

Second patch indicates that there are some missing files, can someone intimate with the JRE plugin comment? This was a "typical" install followed by a visit to http://home.netscape.com/plugins/jvm.html, followed by a directory compare against the installed version that fails.

bug happens for me if I installer with the stub (native) installer if I have a profile already established on the machine. I fail to see the connection between profiles and the JRE at this point.

are we sure that we have the same version of the JRE on the smartupdate (it is smartupdate, right) download page as we are currently shipping? cc'ing jcall and maier for help figuring out what we have on the download page.

Do we have two different Java versions here? I think we use 1.3.1 now but used to use 1.3.0_x

Here are stack traces of the various threads when we are "hung" #0 0x405592c7 in __poll (fds=0x830a1a8, nfds=3, timeout=9) at ../sysdeps/unix/sysv/linux/poll.c:63 #1 0x40369485 in g_main_poll () from /usr/lib/libglib-1.2.so.0 #2 0x40368dca in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #3 0x403691cc in g_main_run () from /usr/lib/libglib-1.2.so.0 #4 0x4027fe57 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #5 0x40876f70 in NSGetModule () from /tmp/nsinstallertest/components/libwidget_gtk.so #6 0x40710a5a in NSGetModule () from /tmp/nsinstallertest/components/libnsappshell.so #7 0x0804f8bf in main1 () #8 0x08050165 in main () #9 0x4049eb65 in __libc_start_main (main=0x8050038 <main>, argc=1, ubp_av=0xbffffa44, init=0x804b2d0 <_init>, fini=0x8051e78 <_fini>, rtld_fini=0x4000df24 <_dl_fini>, stack_end=0xbffffa3c) at ../sysdeps/generic/libc-start.c:111 #0 0x405592c7 in __poll (fds=0x8103f14, nfds=1, timeout=2000) at ../sysdeps/unix/sysv/linux/poll.c:63 #1 0x401d97b0 in __pthread_manager (arg=0xb) at manager.c:148 #2 0x401da29b in __pthread_manager_event (arg=0xb) at manager.c:230 #0 0x405592c7 in __poll (fds=0xbf7ffa9c, nfds=1, timeout=28948) at ../sysdeps/unix/sysv/linux/poll.c:63 #1 0x401be684 in PR_Poll () from /tmp/nsinstallertest/libnspr4.so #2 0x4077af22 in NSGetModule () from /tmp/nsinstallertest/components/libnecko.so #3 0x401375fa in nsThread::Main () from /tmp/nsinstallertest/libxpcom.so #4 0x401bf6ee in PR_Select () from /tmp/nsinstallertest/libnspr4.so #5 0x401d9a4f in pthread_start_thread_event (arg=0xbf7ffc00) at manager.c:274 #0 0x404af585 in __sigsuspend (set=0xbf5ff9b8) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 #1 0x401dc4b9 in __pthread_wait_for_restart_signal (self=0xbf5ffc00) at pthread.c:896 #2 0x401d8a59 in pthread_cond_wait (cond=0x810089c, mutex=0x81217c8) at restart.h:34 #3 0x401bb3fe in PR_WaitCondVar () from /tmp/nsinstallertest/libnspr4.so #4 0x407903b3 in NSGetModule () from /tmp/nsinstallertest/components/libnecko.so #5 0x4079000b in NSGetModule () from /tmp/nsinstallertest/components/libnecko.so #6 0x401375fa in nsThread::Main () from /tmp/nsinstallertest/libxpcom.so #7 0x401bf6ee in PR_Select () from /tmp/nsinstallertest/libnspr4.so #8 0x401d9a4f in pthread_start_thread_event (arg=0xbf5ffc00) at manager.c:274 #0 0x404af585 in __sigsuspend (set=0xbf3ff990) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 #1 0x401dc4b9 in __pthread_wait_for_restart_signal (self=0xbf3ffc00) at pthread.c:896 #2 0x401d8a59 in pthread_cond_wait (cond=0x81040fc, mutex=0x81214a8) at restart.h:34 #3 0x401bb3fe in PR_WaitCondVar () from /tmp/nsinstallertest/libnspr4.so #4 0x401381a5 in nsThreadPool::GetRequest () from /tmp/nsinstallertest/libxpcom.so #5 0x4013881e in nsThreadPoolRunnable::Run () from /tmp/nsinstallertest/libxpcom.so #6 0x401375fa in nsThread::Main () from /tmp/nsinstallertest/libxpcom.so #7 0x401bf6ee in PR_Select () from /tmp/nsinstallertest/libnspr4.so #8 0x401d9a4f in pthread_start_thread_event (arg=0xbf3ffc00) at manager.c:274

ok, now I can hang with the bits downloaded from netscape.com/plugins

(from the Reporter, in response to earlier question) Now that I've deleted the "default" profile, leaving only a single profile for myself, Mozilla starts, and I can use Java and flash plugins.

It seems that I have the same problem with Win98. Update OS to "all"?

win98 works fine for me with multiple profiles (>1). I tried a full install and also a recommended, then triggering jvm.xpi. Both worked fine without errors. What's the error you're seeing under win98?

jvm.xpi does not exist. I meant: ftp://ftp.netscape.com/pub/netscape6/english/6.0/unix/linux22/xpi/jre.xpi

Looks like this was somehow fixed for linux on the trunk. Linux trunk build 2001071008 shows this bug but on build 2001071021 its fixed. Unfortunately, this is still broken on the branch.

Just a quick guess, but brian checked in a Mac plugin fix on the tenth that might have fixed this problem. the bug ID for that is bug 85231. Thanks shannon for pointing this out. I'm applying his patches to my debug build (last updated on the ninth) to see if this works. Brian, any idea if your patch fixed this problem as well?

cancel the last comment, brians patches didn't do the trick for me.

Sean Su: Hello! On 2001-07-09 the bug 64351, which I have opened, was marked as a duplicate of this one. The problem: If I try to enter a site with java-applets (JRE 1.3.0_01 is installed through mozilla), Mozilla crashes and talkback appears. I really don´t know if the bugs have the same origin. Bye, Daniel

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

Do we need to bring any more help on this one? Who do we want?

I'm now able to reproduce this easily by simply blowing alway my ~/.mozilla directory. Starting back up after killing the frozen task seemed to make Mozilla work okay. The installer may be off the hook because everything works fine as long as we don't go into profile migration after having installed Java. In fact, I can even reproduce by doing: 1) Typical install 2) Install Java (either from web or manually create symbolic links) 3) Exit 4) Remove ~./mozilla 5) Start Netscape and notice the same hang, except I got the Activation window (still catatonic) to appear for a few moments. Having said that, I think this bug may belong to whomever owns the "Migrate Profile Routine" because that's where it seem to freeze and it's the last thing on the console.

Peter, I am not sure it is just profile migration. I can go into profile manager and create a profile and hang also. I can have my profile migrated from an earlier test and it will not be usable after I install Java.

Shannond discovered that a checkin on July 10 between 08:00 a.m. and 09:00 p.m. fixed this problem on the trunk. I verified that yes this is fixed in the trunk with a single profile (no .mozilla directory) and multiple profiles. If anybody knows what checkin fixed this problem, please inform the masses. I've tried looking on bonsai.mozilla.org to see what checkin it could possibly be, still haven't found it since there were NUMEROUS checkins during that period. I'm currently patching up my debug branch build one checkin at a time which really isn't producing any significant results...for me anyway. If anybody knows an easier way to find out what fixed this bug, please advise. Here is the URL of all the checkins to the trunk on July 10 between 8 a.m. and 9 p.m. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Change+Size&hours=2&date=explicit&mindate=07/10/2001+08:00:00&maxdate=07/10/2001+21:00:00&cvsroot=/cvsroot Hope this helps us narrow down what fixed this problem.

sweetlou no longer has the 2001-07-10-08-trunk bits (but you can still get the working 07-10-21-trunk). If you want a copy of the last bad trunk bits e-mail me and I'll let you where to get em on my machine.

Syd and I are seeing the same thing, trunk works, branch doesn't. This could possibly be caused on the branch only because of bug 87913. That patch still needs to be backed out of the branch but it's already out of the trunk. It changed binary compatiblity of the component manager, however, that checkin was made on the 11th, not the 10th. I'll try backing out that change tonight and we'll see if this bug gets fixed tomorrow.

Yes, only branch. I see the profile manager dialog come up and go away just before hanging. But that doesn't prove anything to me regarding where the blame lies.

Grace mentioned that we see this even with new profiles. Peter did you notice that ? Getting linux bits from sweetlou.

I am not sure if this is a profile migration issue unless it is something new that need to be taken care of (due to other changes). Getting all my builds ready. Adding Putterman, Conrad and Seth to the list.

I've got a debug build and have the plugins folder filled in. Some interesting things, if I remove .mozilla and run, the activation window comes up but the content does not display (there are a bunch of JS errors that display). After a while the timeout occurs for the registration window and then it hangs. Like before the stack trace tells me nothing. If I ctrl-C and restart, with a .mozilla folder now in place everything runs great.

So, the next step was to leave everything the same, remove the Java plugin, and try the same tests. Now I can't break it. This is *long* after installer, I'm just playing with stuff in a directory on my machine. So you *know* that the java plugin being there is hosing us, because I can't crash it no matter what the profile situation is (i.e., regardless of my deleting .mozilla or not). It is probably *not* component registration, as that happens only once, not each time I run. So, I really need to know the following from someone -- what is the interaction between mozilla and this java plugin each time the browser is started? Do we call into the java plugin each time we startup? If so, what is done? I think we should focus on that code and see if anything is getting trashed.

If this is Buvhan's bug, then I'm Britney Spears. Reassigning to Peter to help me understand the pluggin issues.

I commented out the call to nsPluginHostImpl::LoadPlugins. This fixes things too.

OK, this is interesting, and the best clue so far. Seems that LoadPlugins happens when a docshell is created. Guess when the first docshell is created? Yes, when the window that shows the barber pole is displayed, showing you profile migration. And we hang after that docshell is destroyed. Obviously, then, but not removing the .mozilla folder, we are deferring creation of a docshell, and thus loading of plugins until later in the startup sequence. Perhaps the problem isn't one of memory corruption (after all, we have seen both profile migration, and java plugin work fine, just not fine together). Perhaps it is one of timing.

Just to clarify, when I refer to timing, I think this is about stuff happening too early, or a docshell going away to soon. If I comment out the call to show the little progress bar dialog, I get past this problem. I'll attach a patch. This patch is not the fix, necessarily.

Index: pref-migrator/src/nsPrefMigration.cpp =================================================================== RCS file: /cvsroot/mozilla/profile/pref-migrator/src/nsPrefMigration.cpp,v retrieving revision 1.144.24.1 diff -u -r1.144.24.1 nsPrefMigration.cpp --- nsPrefMigration.cpp 2001/06/25 13:59:53 1.144.24.1 +++ nsPrefMigration.cpp 2001/07/17 04:59:30 @@ -309,7 +309,8 @@ nsPrefMigration::ProcessPrefs(PRBool showProgressAsModalWindow) { nsresult rv; - + +#if 0 nsCOMPtr<nsIWindowWatcher> windowWatcher(do_GetService("@mozilla.org/embedcomp/window-watcher;1", &rv)); if (NS_FAILED(rv)) return rv; @@ -321,6 +322,7 @@ nsnull, getter_AddRefs(mPMProgressWindow)); if (NS_FAILED(rv)) return rv; +#endif return NS_OK; }

okay, I can also hang if I give it a --profilemanager argument. So, this is all about window creation, not profile migration or java. Or maybe java plugin initialization can't handle its docshell being closed, according to dan veditz.

In the bonasi query pasted by Rodney Velasco 2001-07-16, it looks like Timeless made some check-ins to nsWindow.cpp and nsWidget.cpp. Could this explain Syd's window timing theory?

No. Dan and I applied those changes. There was no effect. I think there is a real problem here of some kind. Let's look for the real bug and get this solved.

nsDocShell::NewContentViewerObj() appears to be trying to load the plugins only when we can't otherwise find a doc loader factory with which to view content. What is |aContentType| when you hit this code?

Peter and I discovered if we call the profile migration code in nsAppRunner.cpp *after* we allow the hidden window to be created, then the plugin loading triggered off the docshell works great. Dan Veditz has suggested maybe there is a dependency on hidden window, is that possible? Chris, I'll look into your question.

Well, the plugin loading code shouldn't be triggered off the docshell unless we're trying to load a content type that mozilla doesn't know about. So, what content type are we trying to load that mozilla doesn't know about?

So, what if you make the hidden window earlier. There is this comment here: http://lxr.mozilla.org/mozilla/source/xpfe/bootstrap/nsAppRunner.cpp#1145 but I'm pretty sure that's not true anymore.

Thanks to Syd's detail in debuggin', he found the problem. It seems that the profile migration code happens BEFORE the hidden window is created.

But still, what's the actual problem? Why should migration have to happen after the hidden window is created? The whole point of windowwatcher is that it can make windows with or without a parent and without affecting or being affected by the hidden window. If that's not the case, there's a problem. Making the hidden window before migration might do the trick, but...

Will somebody please determine what MIME type is failing before we wallpaper over another gaping hole? Thanks.

Right, and when we changed the order of the hidden window creation vs. the profile migration in the AppShell, it worked great! However, we then noticed that the profile manager has this same problem, that window is created BEFORE the hidden window is shown. To explain the relationship between LoadPlugins() and the hidden window, is that when the hidden window is created it is created with a script context. This, in turns, causes LiveConnect to init which in turns causes the JVMManager to start which in turn attempts to LoadPlugins() to see if Java is there. Ed Burns says in e-mail that this is really touchy. Our idea of having LoadPlugins() create the hidden window if it hasn't been created didn't work. What worked very well was adding an EnsureScriptEnvironment() call in the Docshell before we call LoadPlugins(). We don't know the docshell code well enough to understand the side effects of this, but it would sovle this problem in one line. Checking content-type next.

Waterson, the content type is application/vnd.mozilla.xul.+xml. Should we just special case this?

Is it _exactly_ "application/vnd.mozilla.xul.+xml"? If so, it _should_ be application/vnd.mozilla.xul+xml and somebody is screwing it up somewhere. LXR couldn't find any instances of the string you typed, so did you miskey it? If not, maybe someone mangled a strcat() along the way to the docshell?

Sorry, it is exactly: "application/vnd.mozilla.xul+xml" Here is a link to the full text search: http://lxr.mozilla.org/seamonkey/search?string=application%2Fvnd.mozilla .xul

Okay, so -- we should be able to create a doc loader factory for that MIME type; specifically, content/build/nsContentDLF.cpp is able to handle it. I dug around a bit but couldn't find where on earth we actually _register_ the component ID properly, though. What does the stack trace look like at the time we try to |do_CreateInstance()| the DLF? Presumably we'll unwind to the caller with a failure code, who'll have some hard-coded knowledge about using the built-in DLF? Maybe we just need to reverse that, so we try our DLF first before throwing it at the docshell. Alternatively (and probably better), we could make sure that we properly register all the DLF's contract ID's. I've finally got the JRE installed, so I'll dig at it a bit, too.

What if the call to LoadPlugins() was completely removed from the docshell? I don't think we need it here because plugins will be loaded by the JVMManager anyway.

It's conceivable that someone would want plugins without a JVM (e.g., embedded on a device), but that may be a reasonable way to fix this on the branch.

I think nsContentDLF is unused code and you should be modifying nsLayoutDLF. See bug 87476.

Peter, not sure how you came to this conclusion, maybe we had a testing error or something, but adding a call to EnsureScriptEnvironment() does not fix the problem. The only fix I have seen is to get a hidden window created ahead of time, for whatever reason. cc'ing patrick beard at the request of PDT.

If I don't install Java, would Peter's proposal result in plugins not working? That wouldn't be OK since not all users take Java from our installs. Is it reasonable to create a patch based on Chris's comment about the MIME type?

I just chatted with Syd and he says there is even a latter call to LoadPlugins() is causing the same problem if the one in docshell is commented out. We're trying to get a stack. I think I've got reproducing down. Starting mozilla with the -ProfileWizard switch can trigger this every time for me without deleteing any files.

I've tried narrowing down which check-ins fixed the trunk. On 7/10 at 16:00 we hang, and at 16:50 we don't (incorporating one later typo build-bustage fix). I'm trying to narrow it down further, but having to clobber my build. Don't see how any of the 3 checkins in that time block would affect startup ordering.

so, a couple of answers to a couple of questions. 1) no, the plugins are not being unloaded when the windows (profile) go down. 2) I still get the bug if I remove the call to LoadPlugins from inside the docshell stuff. It just gets called elsewhere, as in the following stack. Makes me think that we need to make it work instead of trying to not make it happen. #0 goobooroo () at prmem.c:37 #1 0x40b2df89 in nsPluginHostImpl::LoadPlugins (this=0x80fdd68) at nsPluginHostImpl.cpp:3940 #2 0x40b2d2f1 in nsPluginHostImpl::GetPluginFactory (this=0x80fdd68, aMimeType=0x40a342b1 "application/x-java-vm", aPlugin=0xbfffe43c) at nsPluginHostImpl.cpp:3685 #3 0x40a26630 in nsJVMManager::StartupJVM (this=0x840cf38) at nsJVMManager.cpp:602 #4 0x40a26bee in nsJVMManager::MaybeStartupLiveConnect (this=0x840cf38) at nsJVMManager.cpp:783 #5 0x40a2cc2f in nsJVMManager::StartupLiveConnect (this=0x840cf38, runtime=0x810a440, outStarted=@0xbfffe538) at nsJVMManager.h:128 #6 0x41bed87b in nsJSEnvironment::nsJSEnvironment (this=0x840ce98) at nsJSEnvironment.cpp:1527 #7 0x41bed265 in nsJSEnvironment::GetScriptingEnvironment () at nsJSEnvironment.cpp:1446 #8 0x41bedcf4 in NS_CreateScriptContext (aGlobal=0x83e86d0, aContext=0x83e7f20) at nsJSEnvironment.cpp:1574 #9 0x41be5c74 in nsDOMSOFactory::NewScriptContext (this=0x83e8668, ---Type <return> to continue, or q <return> to quit--- aGlobal=0x83e86d0, aContext=0x83e7f20) at nsDOMFactory.cpp:123 #10 0x42b15a15 in nsDocShell::EnsureScriptEnvironment (this=0x83e7e70) at nsDocShell.cpp:5830 #11 0x42b17b24 in nsWebShell::GetInterface (this=0x83e7e70, aIID=@0x40d28e54, aInstancePtr=0xbfffe850) at nsWebShell.cpp:322 #12 0x401e9f1e in nsGetInterface::operator() (this=0xbfffe8d0, aIID=@0x40d28e54, aInstancePtr=0xbfffe850) at nsIInterfaceRequestor.cpp:37 #13 0x40d1c014 in ?? () from /opt/raptor/branch/ns/dist/bin/components/libembedcomponents.so #14 0x40d1eaa0 in ?? () from /opt/raptor/branch/ns/dist/bin/components/libembedcomponents.so #15 0x40d12925 in ?? () from /opt/raptor/branch/ns/dist/bin/components/libembedcomponents.so #16 0x40d0f549 in ?? () from /opt/raptor/branch/ns/dist/bin/components/libembedcomponents.so #17 0x40d0e6d9 in ?? () from /opt/raptor/branch/ns/dist/bin/components/libembedcomponents.so #18 0x42b5491c in nsPrefMigration::ProcessPrefs (this=0x83e7ae0, showProgressAsModalWindow=0) at nsPrefMigration.cpp:322 ---Type <return> to continue, or q <return> to quit--- #19 0x420e33e3 in nsProfile::MigrateProfile (this=0x83d5320, profileName=0x83e7b48, showProgressAsModalWindow=0) at nsProfile.cpp:1957 #20 0x420e3d68 in nsProfile::MigrateAllProfiles (this=0x83d5320) at nsProfile.cpp:2086 #21 0x420dc44c in nsProfile::AutoMigrate (this=0x83d5320) at nsProfile.cpp:610 #22 0x420dd6e3 in nsProfile::ProcessArgs (this=0x83d5320, cmdLineArgs=0x8249888, profileDirSet=0xbffff5e8, profileURLStr=@0xbffff5c0) at nsProfile.cpp:841 #23 0x420dad70 in nsProfile::StartupWithArgs (this=0x83d5320, cmdLineArgs=0x8249888, canInteract=1) at nsProfile.cpp:376 #24 0x080592f6 in InitializeProfileService (cmdLineArgs=0x8249888) at nsAppRunner.cpp:904 #25 0x0805a81d in main1 (argc=1, argv=0xbffff9d4, nativeApp=0x0) at nsAppRunner.cpp:1191 #26 0x0805b83f in main (argc=1, argv=0xbffff9d4) at nsAppRunner.cpp:1532 #27 0x405b1b65 in __libc_start_main (main=0x805b640 <main>, argc=1, ubp_av=0xbffff9d4, init=0x8053fe4 <_init>, fini=0x8066f20 <_fini>, rtld_fini=0x4000df24 <_dl_fini>, stack_end=0xbffff9cc) at ../sysdeps/generic/libc-start.c:111 (goobooroo is my little hack to get me a breakpoint in gdb without loading the .so, which would be too late) I think we have to understand what (if there is one) the dependency on a global window is all about.

This sounds very much like bug 87843 which happened to be fixed right around the time this one was opened. David Baron fixed the problem with the nsDeviceContextGTK but perhaps there is something additional that needs to be done for Java to work. cc:ing Marc and Brendan, reviewers from bug 87843.

Although it may *sound* like bug 87843, the underlying cause is most likely very different. The problem in bug 87843 is now fixed.

Bug 87843 was about the screen resolution not being calculated, or being calculated incorectly, when the activation window was drawn. The telltale sign of that bug was: ###!!! ASSERTION: Negative Width Input - very bad: 'mComputedWidth>=0', file nsHTMLReflowState.cpp, line 2472 I don't think it's similar.

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

Change subject.

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

After working with Ed burns, here's my first attempt at a patch of hackery to actually fully fix this. Please review and comment, maybe someone has a better idea. I tested this out only on Linux branch so far in the following situations: 1) No .mozilla and profile migration 2) One profile and no proifle manager 3) Several profiles and the profile manager come sup 4) Using the --ProfileWizard switch All of those work for me with this patch plus on each one, I verified that Java was working by visiting http://www.javasoft.com Marc suggested that Liveconnect be tested as well. Could someone more familiar with Liveconnect either try this or point me to a testcase? Thanks!

Lamentably, the hack breaks liveconnect. Peter, you need to make it so the hack is in place if and only if we're in the (ProfileManager|ProfileWizard|Profile Migration) case. If I remove the hack and start mozilla with only one profile, liveconnect works.

Peter would it be possible to look for the existence of some service that only is known to exist during the *real* browser running situation? How could we determine whether or not we're in the *real* browser case, or in the "before the browser really starts" case?

Does it still solve the problem to create the hidden window before calling InitializeProfileService()? That seems like a bit less of a hack than changing nsJVMManager.cpp. All you'd have to do is move nsAppRunner.cpp#1147 up to #1134. The comment at #1145 just isn't so. You'd have to make a new scary comment though.

dbaron and I updated modules/libpref/src/init/all.js from r3.252 to r.3.253, and it fixes the problem. This was the magic checkin that ``fixed'' things on the trunk. cc'ing jesse, who came up with the patch.

Heh, here's the fix: Index: all.js =================================================================== RCS file: /cvsroot/mozilla/modules/libpref/src/init/all.js,v retrieving revision 3.245.2.7 diff -u -r3.245.2.7 all.js --- all.js 2001/07/17 03:40:18 3.245.2.7 +++ all.js 2001/07/19 03:04:17 @@ -230,6 +230,10 @@ pref("capability.policy.mailnews.sites", "mailbox: imap: news:"); pref("capability.policy.mailnews.Window.name.set", "noAccess"); pref("capability.policy.mailnews.Window.location", "noAccess"); +//////////////////////////////////////////////////////////// +pref("capability.principal.codebase.foo.id", "http://www.netscape.com"); +pref("capability.principal.codebase.foo.granted", "UniversalFoo"); +////////////////////////////////////////////////////////// pref("javascript.enabled", true); pref("javascript.allow.mailnews", false);

From a conversation with mstoltz, this fix was checked in accidentally (along with jesse's changes that were meant to be checked in). It shouldn't actually do anything, but it probably affects initialization order in some way that fixes this bug.

Glad to see that the stench of the hack that Peter and I were working on was enough to wake people up from their torpor. Waterson's all.js patch works like a charm. linux: ./mozilla --ProfileWizard -> browser, with java and liveconnect works fine ./mozilla (two profiles) -> browser with java and liveconnect works fine ./mozilla (one profile) -> browser with java and liveconnect works fine.

The presence of those lines in all.js (which were checked in by accident) cause the for loop in nsScriptSecurityManager::InitPrincipals to iterate once. Without those prefs, aPrefCount will probably be zero, and the code in the for loop will never run. My guess is that the code in that for loop is affecting initialization order somehow.

Great work Waterson! Get that into the trunk!

..er..I mean branch!

Wow, finally a fix. Don't mean to be a bringdown since you all found the fix.....but anybody know why xpicleanup is still running after you install the JVM, and restart browser? I get this dialog box "The program must close to allow a previous installation attempt to complete. Please restart" Right after I installed the jvm from http://home.netscape.com/plugins/jvm.html and file -> quit the browser. I need to start the netscape binary about two times before I can actually get the Profile Manager window (which actually works when I choose a profile..yeah). With that said, I'll file another bug on this...I'm sure most of you hate to see the word 'catatonic' in your mailbox.

bug 91427 filed for above issue I described.

The replacement utility has a far too long sleep cycle, resulting in most people being able to re-launch Mozilla again before xpicleanup realizes Mozilla has shut down and gotten out of its way.

Has anyone already checked in the fix from Chris Waterson 2001-07-18 20:07? We need this in to make the next build a viable candidate build. I've asked dveditz to do the checkin if it hasn't been done and nobody is around.

Checked in to MOZILLA_0_9_2_BRANCH, 2001-07-19 01:02 PDT, all.js rev. 3.245.2.8.

Thank You Thank You Thank You!!!

Yes!!! fixed on branch build 2001-07-19-04-0.9.2

not to rain on dbaron and waterson's parade, but... we're going to keep this open though and find and resolve the real underlying problem, right? Otherwise what are we going to do when someone removes those prefs for some reason and it comes back...

Uh, yeah. I hope so. In fact, I think mstoltz is going to back the spurious ``fix'' out on the trunk, so we'll soon be able to debug the problem there.

Reassigning to mstoltz...

The comments suggest that this is checked in. But I just installed the 20010719 4am branch build (net installer, checked ALL to get Java) and when I go to http://www.shallowsky.com/jupiter.html (which has an applet on it) the app hangs before it even loads any of the page, while displaying "Connecting to ..." in the status bar. This is repeatable. The page works in other java-enabled browsers (e.g. galeon). Am I seeing a different bug, or did the fix somehow not make it into 20010719?

akkana, you might be seeing the 'lazy java loading' thing fixed with bug 26516.

If so, it needs to be done differently. The fact is that going to a page containing java completely locks up the browser (presumably forever, but I only timed it for 3 minutes -- should I wait longer than that? The whole app never used to take that long to start up) so that you have to kill the app externally and start over. BTW, this build is: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010719 Netscape6/6.1

Akkana: You're probably seeing bug 84093 if you're running RedHat 7.1.

Yes, I'm seeing bug 84093.

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

I don't understand, why was this assigned to me? Shouldn't we come up with a real fix before I back out the accidental fix and reopen the blocker? Back to peterl.

Mitch, I assigned it to you because I thought nobody knows more about this mysterious pref than you and maybe you could shed some light (in greater detail) as to what this pref actualy does? Do you have ANY ideas WHY Java MUST have this pref set? Using this pref trips _something_ pretty important in security that makes the browser not hang with Java. Also, what's wrong with considering keeping this pref as the REAL fix? I agree the name is awful, but what's wrong with replacing "foo" with "oji" or something like that? I think the problem is with the interaction of browser security and OJI. Even if I did understand the real problem, I don't know enough about OJI or security to fix it. Reassigning to OJI.

I mentioned above what those prefs do - they cause some additional initialization code to run as nsScriptSecurityManager is initialized. I don't know how or why that affects java, and I'd really like to see this fixed at the root of the problem, not haphazardly. Does anyone know when this started/what checkin caused the bug to begin with?

Over the weekend I debugging this a bit and found that the hang was happening where the OnStartRequest for the load of navigator.xul was sent into a proxy and never came out on the other side and got handled by the main thread. On a suggestion from a conversation with darin and gordon (that in the past there was a bug with the cache where holding on to an event queue would stop events from being processed), I debugged this a bit with danm. We found that: * when Java was not installed, there are two event queues destroyed, one right after the profile manager closes (right before the load of navigator.xul starts) and the other at app shutdown * when Java is installed and we don't grant UniversalFoo, the first destruction doesn't happen and the navigator.xul load events that are dropped go through the codepath in PostEvent that punts to an elder queue. * when Java is installed and we do grant UniversalFoo, the event queue destruction at app shutdown doesn't happen, but the one after the profile manager closes does happen (which presumably causes us to run correctly) So it seems like this bug might be related to holding on to an event queue. It's not fully understood why this causes a hang, but the solution may just be not to hold on to the event queue. danm says the event queue stuff is very fragile and changing that might not be a good idea. (Or something like that...) Is the Java plugin holding on to the event queue somehow? (It's an XPCOM plugin, right?) If so, could it be changed not to do so?

It would be nice if someone who has access to the source of the Java plugin (Ed Burns?) could investigate my last comment. The "UniversalFoo" hack really shouldn't be the permanent fix for this bug.

With 0.9.1, I installed the java plugin (1.3.0_01). When starting 0.9.2 or 0.9.3, I had the "Mozilla needs to shutdown to allow a previous installation to finish" error message. I rm -rf my .mozilla directory, run mozilla as root, to no avail. Following the thread here, I remove the symlink /usr/lib/mozilla/plugins/libjavaplugin_oji.so, ran mozilla as root (it worked), rm -rf .mozilla, and run mozilla as a user. It worked. After that, I've put back the symlink for /usr/lib/mozilla/plugins/libjavaplugin_oji.so, and mozilla started, although java is not working (complete hang). Galeon (0.11, 0.11.1, 0.11.2, 0.11.3) does not have those problems.

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

Priorities in the new economy.

SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)

this checkin has a significant negative effect on startup time, because it forces http to initialize during startup. http in turn causes several other components to be initialized. could we get by with just changing the pref to reference about:blank instead of www.netscape.com? any help testing this would be most appreciated. thanks! see bug 97462 and bug 96681

We could probably come up with a better hack anyway -- like doing something that causes the Java library to be initialized before we start the nested event queue for the profile manager. Although, really, it would be nice if the plugin itself were fixed, or if we fixed event queues not to behave this way.

Would a "good" place for a less-invasive hack be nsProfile::LoadDefaultProfileDir, a little before we call OpenWindow?

I don't think so. There is another place in profile startup (Confirming auto-migration) where a modal window is opened with windowwatcher. There may be others. In general, we should be able to open modal windows without hacking around this problem. Let's find a real answer.

OK, I've been assuming that the problem was in the java plugin itself, but I think it's in the JVM manager, so I think we can find a real fix.

Actually, never mind that. The JVM Manager doesn't hold on to the event queue that it gets, so I think the problem is in the Java plugin, which we can't change. Only Sun can, and they don't seem interested in doing that anytime soon.

it sounds to me like someone (maybe the java plugin) has cached an eventQ... Then when a new eventQ is pushed (because of the modal window) some events end up being pushed to the wrong eventQ. This ultimately leads to the hang... -- rick

It's actually a leak of an event queue -- see my comments dated 2001-07-24 15:53.

I assume that the eventQ leaks because someone is holding a reference to it... This is really starting to sound as if the java plugin (or someone) is grabbing an eventQ during early initialization, later posting events to the cached Q (rather than the currently active Q)... Since the eventQ is cached, and everything goes to hell in a hand-basket, we end up leaking the eventQ... Can we add an ASSERT in the event posting code which checks that the eventQ being tageted is the 'active' event Q for that thread? This could catch similar situations in the future :-) -- rick

Whiteboard says 'fixed on branch'. Is that the 0.9.4 branch? If so, could someone please remove the nsbranch keyword to get it off the radar?

It's been fixed temporarily, with a hack of sorts, before 0.9.4 was cut, so removing nsbranch. I would still like this to be fixed soon so we can remove the 'UniversalFoo' hack from all.js.

reassign

Reassign to Joe as I'm leaving the role of OJI module owner.

Ressign to Joe Chou, as I am no longer working officially on OJI.

I just installed mozilla 0.9.4-2 on a system running RH7.1 with the 2.4.3-12 kernel. I still have the same problems I originally had way back with 0.9.1. As root I tried through debug applets. It asked me to download java which I did, and it claimed it was successfully installed. So I exited mozilla and tried to run it again. I got that same old message about mozilla needing to shutdown. This time I was able to kill the running process (although it wasn't up on the screen) and then I could start mozilla. But when I went to test the applets through debug, it hung again just as it always has. It also hung when I tried to test javascript. Is any progress being made on this at all. Or are we just going around in circles. Any suggestions about what I might try?

len: you seem anxious to try something, and I have something you could try. I don't have the JRE on my machine and I'm pressed for time right now. If anyone out there can build with the patch I'm about to post and let me know if it helps... The patch isn't what I'd propose for an actual checkin. I'm just curious whether it fixes the problem. If it does, we at least know for certain that we understand the problem. The patch wants to be tried using some version of the source that doesn't have the 0.9.4 UniversalFoo "fix." That fix just disguises the problem through some mysterious process. It seems to be checked in everywhere; it can be backed out by removing the two lines in all.js that contain the word "foo". I've tried the patch on my machine. It doesn't hurt anything. I'm curious to know whether it helps. Any volunteers? (Lacking a response, I'll try this myself in a week or maybe.)

I just installed version 0.9.5 from the RedHat_7x rpm package As usualy I started at debug and picked applets. That prompted a download of the java plugin and installed it. This time I was able (as root) to close java without any hanging. But when I went back to the debug > applets test, it hung as usual. Why does the Mozilla web page keep saying that Mozilla has been tested with java, when it still doesn't work. It seems to me this is not a minor issue.

Okay. I finally gave up on getting the Java plugin from mozilla which is supposed to automatically find the plugin you need. Instead I went to sun and got the rpm package for jre 1.3.1. In installed that and moved the link in /usr/lib/mozilla/plugins so it pointed at the plugin in the /usr/java/... tree. Now it works. I don't know how long it has been working, but perhaps the web page should be rewritten. It seems to imply that 1.3.0 will work and you get a version of that if you let mozilla automatically get the plugin. But in fact that version doesn't work.

What you're describing sounds like bug 84093 rather than this bug. (I think the web site should have been changed before resolving that bug, but it's probably going to happen sometime, anyway...)

Sun's JRE 1.3.0 does not like RH 7.1 unless your set LD_ASSUME_KERNEL=2.2.5. See bug 84093. The remaining issues with JRE 1.3.1 and Mozilla have been fixed and the next release of Netscape will come with JRE 1.3.1. The web page for download should also be updated soon, see bug 103926.

Re-assign to nidheesh.

Nidheesh, any update on this?

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

Could this be the same issue as bug #99026? If so, perhaps that patch fixes this too :-)

This is fixed in my tree even with the hack removed. (I tested in my Linux debug build by linking the java plugin into the plugins directory, and starting with ./mozilla -ProfileManager. The build started, and java worked.) So here's a patch that removes the hack that is no longer necessary (and causes HTTP to start up earlier, etc., etc.).

hey david, can you tell if it was the patch for bug #99026 that fixed the problem? this patch 'kinda snuck' into the tree as part of darin's nsIChannel changes ;-) it would be nice if we knew *why* we no longer have this problem. -- rick

Yes, it was the patch for bug 99026. (It looks like only the first part of that patch was checked in. When I back out that one line change in my tree, I get the hang again.)

Comment on attachment 77992 [details] [diff] [review] patch to remove hack sr=darin (with pleasure!)

Yeah! finally :-)

Comment on attachment 77992 [details] [diff] [review] patch to remove hack I second that! r=mstoltz.

thank you david!!!!! it's GREAT to get rid of this wacky bug ;-) -- rick

I'm taking this bug with the intent of closing it once the above patch is checked in (and the hack removed), since the real bug in Mozilla is already fixed. There remains the issue of the leak of the event queue within the Java plugin itself, but I'm not sure how to report a bug to Sun on the Java plugin. Having it in bugzilla didn't seem to lead to a fix.

Comment on attachment 77992 [details] [diff] [review] patch to remove hack a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Hack removed 2002-04-08 18:22 PDT. Marking fixed (although it was really bug 99026).

verified on linux redhat 7.1, jre 1.3.1(branch build: 2002-04-17-10-1.0.0). Visiting http://www.java.sun.com, no hang!

verified