Closed Bug 26516 Opened 25 years ago Closed 24 years ago

java/plugins initialize at startup

Categories

(Core Graveyard :: Plug-ins, defect, P1)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: warrensomebody, Assigned: beard)

References

Details

(Keywords: perf, topperf)

Attachments

(7 files)

proposed fix for not registering Java Plugin on startup
637 bytes, patch
Details | Diff | Splinter Review
Fix for this bug, second iteration.
706 bytes, patch
Details | Diff | Splinter Review
rough draft of different approach of not loading JVM
3.68 KB, patch
Details | Diff | Splinter Review
Patch to do 2 phase initialization of JSJavaVM objects.
4.53 KB, patch
Details | Diff | Splinter Review
Better patch (jsj_ConnectToJavaVM checks jsjava_vm->java_vm instead of jsjava_vm->jsj_created_java_vm)
4.24 KB, patch
Details | Diff | Splinter Review
Be more defensive about JSJavaVM usage.
7.80 KB, patch
Details | Diff | Splinter Review
Once more, with feeling, check result of jsj_ConnectToJavaVM()
7.83 KB, patch
Details | Diff | Splinter Review
I've noticed that java initializes on startup, in fact all plugins do. It appears that the plugins directory is iterated through during startup and all the plugins are re-registered (in nsPluginHostImpl::GetPluginFactory). Since plugins can now just be viewed as components, we should rely on the standard component registration in xpcom to manage them. (Wasn't that the whole point of the 4.x plugin adapters, etc.?) nsPluginHostImpl::GetPluginFactory takes 4.07% of startup time after eliminating idle times from Quantify, and time spent in LoadLibrary.
Keywords: beta1, perf
Whiteboard: [PDT+]
Giving to OJI owners.
Assignee: beard → drapeau
OJI is already an XPCOM service, and is registered as such. Java Plug-In is a plugin that asks for the JVMManager XPCOM service. I think there might be a couple of issues here, but Andrei Volkov is better equipped to answer this than I. Here is my belief about the several issues: 1) Old-style plugins aren't loaded as components, so those plugins can't be managed in the XPCOM way (e.g., Shockwave, RealAudio, etc.). 2) Java being initialized on startup is a different bug: I believe that LiveConnect is causing the JVM to be started as a side-effect, a behavior which we will fix after Beta1. I believe that the basic bug as being reported here is "plugins initialize at startup", so I'm re-assigning this to the Plugins module.
Assignee: drapeau → av
Component: OJI → Plug-ins
QA Contact: paw → shrir
Target Milestone: M15
Blocks: 21305
Must land a fix for this by 02/23 or we will PDT- (not fix) for beta1.
Whiteboard: [PDT+] → [PDT+] Must land by 02/23
Whiteboard: [PDT+] Must land by 02/23 → [PDT+] w/b minus on 02/25
I am removing PDT+ mark since 02/25 passed and we do not have fix in hand yet.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] w/b minus on 02/25 → w/b minus on 02/25
Putting on PDT- for beta1.
Whiteboard: w/b minus on 02/25 → [PDT-]w/b minus on 02/25
Target Milestone: M15 → M16
Plugins folder is iterated through looking for old school plugins, and those should be registered at start up. The process on Windows should not be very costy since actual dll's are not being loaded at this time. Java initializes from LiveConnect, so I reassining to LiveConnect people to take a look.
Assignee: av → rogerl
Status: ASSIGNED → NEW
Component: Plug-ins → Live Connect
QA Contact: shrir → rginda
Ah yes, but LiveConnect initializes Java when OJI asks it to. What *exactly* is the bug here, is Java demonstrably slower to start-up than 4X ?
The bug here is that java consumes memory footprint and startup time unnecessarily. It should only get initialized when it's really needed, i.e. when the first applet is loaded.
OK, then I don't think this is a LiveConnect issue. LiveConnect initializes the JVM when requested to do so, which would be at the hands of OJI and drapeau has already indicated that's a Plugin's issue. This finger++ is hardly productive though - I'm happy to work with anybody to address this, I just don't see what LiveConnect can do about it?
Yes, this is a plugins issue. Java is just the worst-case scenario. Just make plugin initialization lazy.
Reassigning back to myself.
Assignee: rogerl → av
Component: Live Connect → Plug-ins
QA Contact: rginda → shrir
I just discovered bug 18277 which is a dup. Av - can you work with drapeau to see who's going to own this?
2 betas would be better than one for shaking out major adjustments to startup... putting on beta2 radar
Keywords: beta1 → nsbeta2
Putting on [nsbeta2-] radar. av already overloaded with beta2 work. This is work for beta3. Putting on nsbeta3 keyword radar.
Keywords: nsbeta3
Whiteboard: [PDT-]w/b minus on 02/25 → [nsbeta2-]
Reassigning to George, who's kindly volunteered to take this on. Thanks George!
Assignee: av → drapeau
Accepting this bug.
Status: NEW → ASSIGNED
M16 has been out for a while now, these bugs target milestones need to be updated.
For the record, it looks like the only reason the plugins dir is traversed on startup is for LiveConnect: nsPluginsDir::nsPluginsDir(unsigned short 1) line 193 nsPluginHostImpl::LoadPlugins(nsPluginHostImpl * const 0x0154f644) line 2605 + 10 bytes nsPluginHostImpl::GetPluginFactory(nsPluginHostImpl * const 0x0154f644, const char * 0x01f6f684, nsIPlugin * * 0x0012fa24) line 2421 nsJVMManager::StartupJVM() line 567 + 32 bytes nsJVMManager::MaybeStartupLiveConnect() line 741 + 20 bytes nsJVMManager::StartupLiveConnect(nsJVMManager * const 0x0154e988, JSRuntime * 0x00c6acf8, int & 0) line 128 + 11 bytes nsJSEnvironment::nsJSEnvironment() line 1291 + 49 bytes nsJSEnvironment::GetScriptingEnvironment() line 1236 + 27 bytes NS_CreateScriptContext(nsIScriptGlobalObject * 0x0154d260, nsIScriptContext * * 0x01548880) line 1331 + 5 bytes nsDocShell::EnsureScriptEnvironment(nsDocShell * const 0x015487d0) line 3825 + 50 bytes nsWebShell::GetInterface(nsWebShell * const 0x015487f4, const nsID & {...}, void * * 0x0012fbf8) line 545 + 19 bytes nsGetInterface::operator()(const nsID & {...}, void * * 0x0012fbf8) line 37 + 31 bytes nsCOMPtr<nsIDOMWindow>::assign_from_helper(const nsCOMPtr_helper & {...}, const nsID & {...}) line 856 + 18 bytes nsCOMPtr<nsIDOMWindow>::nsCOMPtr<nsIDOMWindow>(const nsCOMPtr_helper & {...}) line 553 nsAppShellService::GetHiddenWindowAndJSContext(nsAppShellService * const 0x01560550, nsIDOMWindow * * 0x0012fca8, JSContext * * 0x0012fcac) line 687 + 32 bytes nsAppShellService::CreateHiddenWindow(nsAppShellService * const 0x01560550) line 223 + 40 bytes main1(int 2, char * * 0x00c74090, nsISupports * 0x00000000) line 881 main(int 2, char * * 0x00c74090) line 1099 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1b304() If you disable Java using the Preferences Advanced option, the plugins dir doesn't get traversed at startup. Thus I feel the correct thing to do would be to modify the nsJSEnvironment constructor to move the call to JVMManager::StartupLiveConnect() until it's actually needed. Can someone please tell what I would need to change to do this? Thanks, Ed
Assignee: drapeau → edburns
Status: ASSIGNED → NEW
Pushback
Target Milestone: M16 → M18
Adding pavlov and making 35707 be a dependency. /be
Depends on: 35707
I say yank it out of there. We don't do liveconnect now, and probably never will (given that it's JRI-based, i.e. dependent on the old netscape jvm).
Since when are we not support liveconnect?
Status: NEW → ASSIGNED
Liveconnect is based on JRI and is not part of your JVM. AFAIK, it has never worked in seamonkey, and never will.
Jeff Dyer needs to comment on this one. I believe he *did* have LiveConnect support working. Just in case, I'm adding him to the CC list on this so he can reply.
LiveConnect for JNI is implemented. The JRI based code was ported to JNI sometime last year. It has been working ever since, except as reported in Bugzilla. > AFAIK, it has never worked in seamonkey, and never will. Perhaps you know something I don't.
I only meant the JRI one would never work. I had forgotten that it got ported to JNI. Sorry for the confusion.
Warren: no problem, that's cool, but we still could use some advice about how to fix the bug so that the JVM gets requested to start up only at the moment it's needed, not sooner. If you know anybody who can help, that would be great. Otherwise, I will probably ask Jeff Dyer to help on this one, and he won't be able to get to it right away because he's working on the completion of Java-to-JavaScript security right now.
ETA 28 July 2000
The Java Plugin is registered on startup time, i.e. nsPluginHostImpl::GetPluginFactory nsJVMManager::StartupJVM nsJVMManager::MaybeStartupLiveConnect nsJVMManager::StartupLiveConnect nsJSEnvironment::nsJSEnvironment The Java Plugin is also registered when an applet is loaded. If the Java Plugin is installed, I see nsPluginHostImpl::GetPluginFactory nsPluginHostImpl::SetUpPluginInstance nsPluginHostImpl::InstantiateEmbededPlugin and the debugging message "For application/x-java-vm found plugin C:\mozilla\dist\WIN32_D.OBJ\bin\plugins\NPJava32.dll" If the Java Plugin is not installed, I see nsPluginHostImpl::GetPluginFactory nsPluginHostImpl::SetUpDefaultPluginInstance nsPluginHostImpl::InstantiateEmbededPlugin and message "For * found plugin C:\mozilla\dist\WIN32_D.OBJ\bin\plugins\npnul32.dll" The proposed fix here is to modify nsJVMManager::StartupJVM so that the Java Plugin is not registered on startup, see the attachment at 7/18/00. For the plugins other than Java Plugin, I checked QTV plugin with URL, http://www.apple.com/trailers/paramount/mission_impossible_2/bts_med.html With/Without my fix, the nsPluginHostImpl::GetPluginFactory is not called at startup time. It is called when I load the page and I see the message, "For video/quicktime found plugin C:\mozilla\dist\WIN32_D.OBJ\bin\plugins\npqtplugin.dll" I am not sure if there is other method to register QTV plugin at startup time. According George.Drapeau@eng.sun.com, the issue of not loading JVM at the startup time will be addressed at Bug 18277.
Cc'ing waterson.
I'm currently building. I'll try this when it's built.
I like the simplicity of this fix, but it breaks the Menu function "Tasks- >Tools->Java Console". This fix prevents the body of StartupJVM from ever executing. This needs to execute to enable the Java Console to work.
Thank Ed for caching up the problem of Menu function for Java Console in my proposed fix. I tested your second iteration in following steps, Step 1. start mozilla which loading http://www.mozilla.org Step 2. load an applet, e.g. http://192.9.48.9/products/plugin/1.3/demos/applets/CardTest/example1.html Step 3. select menu "Tasks->Tools->Java Console" which starting Java Console. Everything works fine and the method nsPluginHostImpl:GetPluginFactory. is not called on startup. However, the Java Console doesn't start and I saw memory error in nsJVMManager::ShowJavaConsole(nsJVMManager * const 0x00d93c70) line 146 if I skip the step 2 above.
It looks like the patch #2 will block nsJVMManager::MaybeStartupLiveConnect from ever starting the vm. The problem is that Liveconnect and JVM initializiation are entangled. And, that there is code that depends on a running vm, that doesn't know how to start it. The solution (apparently) was just to start the vm at when the browser loads whether it is needed or not. Bug 27462 is another reason why this is a bad idea. The general solution requires that the vm not be started before it is needed (as is being done in the fix proposed here), and also that code that depends on the vm running, make it run (this part is missing from the proposed solutions).
Jeff, can you please give me some pointers on how to do the second part of what you propose: "code that depends on the vm running, make it run"? Something of the form of filename/line-number pairs or even just class names would be great. Thanks, Ed
I'd start by factoring out LiveConnect and start the vm directly from those places where a running vm (without liveconnect) is needed. Once this is working properly, you can do the same for LiveConnect. Hope that helps to get you pointed in the right direction. Let me know if you want more help.
Making nsbeta3-
Whiteboard: [nsbeta2-] → [nsbeta3-]
Marking mozilla0.9. All tries to reduce mozilla memory footprint are totally useless if Java is adding 7 MB of RAM bloat at each startup. This prevents Java enabled small embedded browsers as well. Please reconsider priority of this bug.
Keywords: mozilla0.9
Adding to tracking bug for startup perf (7251).
Blocks: 7251
*** Bug 42262 has been marked as a duplicate of this bug. ***
reassign to joe
Assignee: edburns → joe.chou
Status: ASSIGNED → NEW
Priority: P3 → P1
*** Bug 18277 has been marked as a duplicate of this bug. ***
Blocks: 1785
Joe, any status?
I have not got a chance to look at this one closely yet. I'll look at it tomorrow.
Jeff, would you be a little more specific about your second part of suggestions?
>------- Additional Comments From Jeff Dyer 2000-07-20 12:57 ------- > >I'd start by factoring out LiveConnect and start the vm directly from those >places where a running vm (without liveconnect) is needed. Once this is working >properly, you can do the same for LiveConnect. All I mean is find the places that the JVM is needed and initialize the Java plugin when execution reaches those places. Then find all the places where Livecconect is needed and initialize Liveconnect when execution reaches those places. Before I'd mess with the code though, I'd do a top-down review of the design to see if there is a need to revise the way either of these components are started. For example, I'd look for any dependencies that force LC to start when the VM is started.
To my understanding, with today's build on Windows, in nsJVMManager::MaybeStartupLiveConnect(void) we make a call to JSJ_ConnectToJavaVM(NULL, NULL) which causes java to start. Specifically, in JSJ_ConnectToJavaVM(NULL, NULL), we check if we hava a Java VM and if we do, we call JSJ_callbacks->create_java_vm(&java_vm, &jEnv, initargs) which starts Java (and the little guy in the system tray). Can this somehow be differed untill needed? It's probably a huge memory and performance gain to lazily start Java. Target milestone is set for M18, I nominate Mozilla 0.9?
Yeah, this bug needs a valid Target Milestone. Joe? /be
Yes, Mozilla 0.9 sounds fine.
Status: NEW → ASSIGNED
Changed milestone from m18 to mozilla0.9.
Target Milestone: M18 → mozilla0.9
Keywords: nsbeta2, nsbeta3 → nsbeta1, topperf
Whiteboard: [nsbeta3-]
this bug has such a long and sorted history.... wondering if the fix for this is well understood and on track for 0.9?
Yes, Mozilla0.9 is too soon for this fix (which is planned to be release on 19th of March?). Based on Jeff's suggestions, the fix seems to have multiple changes, and requires more time to test as well. I've been working on some urgent bugs recently, and I need to change the milestone to Mozilla0.9.1. Any objections?
My only comment is that it's a high priority to improve startup as soon as we can. The faster we can get to this bug the better.
Why not leave this at 0.9 for now -- we're seriously contemplating a numbering change to make the current milestone be 0.8.1 (announcements and roadmap update soon), and I'd hate to take pressure off this bug, or even fiddle with its fields for no gain. /be
Blocks: 71373
This patch attempts to skip the loading of Java from the plugin point of view, as if the libraries weren't in the folder. Check about:java and they aren't even registered. However, now that nsPluginHostImpl::ReloadPlugins() works, I set flags to trip skip loading until it finds the Java mime-type. However, there are a few bugs left like it calls ReloadPlugins twice and the Java Console Menu Item stays disabled. Also, I haven't tested this patch extensivly, I don't know what I broke (LiveConnect, which I was told does not work anyway, perhaps?). Seems to save loading time and memory on my system.
LiveConnect *does* work; not completely, but we're fixing LiveConnect bugs as we encounter them. Shrirang or Raju, can either of you point Peter to some LiveConnect tests that he could try with his patched build?
Most of the Test case we have are inside SUN. Not sure if Peter would be able to access those. There are some on the mozilla site (mayb devlped by Shrirang). http://www.mozilla.org/quality/browser/front-end/testcases/oji/ He should be able to find some tests there.
Wait a sec, LiveConnect does work? I was told it doesn't. Does it work/will it work for 4.x plugins if we hook up the Java functions for LiveConnect in ns4xPlugin? I think plugin vendors would be VERY happy if we could provide backwards support for LiveConnect.
Blocks: 71781
No longer blocks: 7251
Oops, sorry about that. I don't know if LiveConnect works for plugins. I know it partially works for Java applets calling JavaScript and vice versa, but I don't know about how plugins fit into the scheme. Do you have a test we could try?
I don't know how to evaluate Peter's changes to see if they're good or not. The change sounds like a hack, but it looks like it works! Who am I to block this fix? I am *not* Brendan Eich, or Patrick Beard, or Ed Burns. So, I'm copying them to see if they can make a ruling. Also, does anybody know here why LiveConnect doesn't work in plugins? Could use some explanation/help/history here, or elsewhere if this bug is not appropriate.
@@ -3319,9 +3329,12 @@ { // do not do anything if it is already done // use nsPluginHostImpl::ReloadPlugins to enforce loading - if(mPluginsLoaded) + if(mPluginsLoaded && mLoadJava) + return ReloadPlugins(PR_FALSE); + else if (mPluginsLoaded) return NS_OK; could be: if(mPluginsLoaded) - return ; + return (mLoadJava)?ReloadPlugins(PR_FALSE):NS_OK; indentation of patch looks inconsistent, and possibly tab ridden, esp near +void nsPluginHostImpl::EnableJava(PRBool aLoadJava) +{ + if (mJavaCalledBefore) + mLoadJava = aLoadJava; + else + mJavaCalledBefore = PR_TRUE; } why reset mJavaCalledBefore ??
If we don't load Java/OJI at startup, won't LiveConnect fail to initialize? Before we check in lazy initialization, I'd like to verify that the code in DOM that initializes LiveConnect still works.
Blocks: 7251
Keywords: nsCatFood
Joe, any word on this? Can someone answer beard's question?
I am trying to figure out Jeff Dyer's suggestion, in compairesion with the patches provided here. I think we all agree with Patick here that the fix should not break liveConnect.
Andrew or Peter can you guys also help take a look at this?
No longer blocks: 71373
I'll take a look at it tonight.
I agree that we can probably defer the call in nsJSEnvironment::nsJSEnvironment() that eagerly calls nsILiveConnectManager::StartupLiveConnect(), but as soon as the first nsJSContext object gets created, its nsJSContext::InitializeLiveConnectClasses() method will get called, and so we'll have to do it there, which is still too eager. The solution to this problem is to initialize the nsJSContext's global object with the LiveConnect root properties, "Packages", "java", and "netscape", such that the first time they are evaluated, THEN the call to nsILiveConnectManager::StartupLiveConnect(), and nsILiveConnectManager::InitLiveConnectClasses() occurs. What I'm not clear on, is how to do this handoff cleanly, such that after this has happened, the values for these properties change to their proper values. jband and brendan can provide more technical details.
jst, what's the best way to define properties lazily? There are the aLazyPropSpec params to nsJSUtils::nsGlobalResolve and nsGlobalEnumerate, which come from 'replaceable' DOM IDL attributes, but DOM IDL is going away. There is the nsIScriptNameSpaceManager/nsIScriptNameSetRegistry jazz, but I believe that too is changing on the DOM-over-XPConnect branch. Pls. advise, /be
No longer blocks: 7251
I've been trying different test cases with some code changes, and found out the following: The main problem seems to be to delay starting LiveConnect (if it is done correctly, lazy starting JVM seems requiring no code change). An ideal place to start LiveConnect would be when a page is found to have JavaScript data types. But in my tracing, I've not found the code parsing JavaScript data types (Packages, java, etc.) in a page. Instead, I did see the code that initializing all the JavaScript data types for any page. If that is true (currently the browser does not parse to see if a page contains JavaScript), then I guess we may need to add code to do the parsing, and if a page is found to have JavaScript, start LiveConnect (along with starting JVM, as the current code does). Am I missing something here?
Can we adapt the ResolveStandardClasses stuff for LiveConnect? That'd let us pull in JavaPackage and the like when they're first used. Parsing the script and looking for references to Package and whatnot is a non-starter, really, since it requires evaluation of the script. Should I look at doing JSJ_ResolveLiveConnectClasses? joe.chou, can you post your patches that get the non-LiveConnect issues resolved?
shaver is referring to the JS API's JS_ResolveStandardClass, which tries to bind a standard name to its property value (Object, Date, RegExp, etc.) and returns a flag telling whether it did bind. JSJ_ResolveStandardPackage is a better name for the liveconnect function, as "Packages", "sun", "netscape", and "java" are package, not class, names. The call would come from GlobalWindowImpl::Resolve, in dom/src/base/nsGlobalWindow.cpp. /be
I'm posting this message on behalf of Joe to say that he has been away since Monday, and is expected to be back tomorrow. That's why there's no progress on this bug since Brendan's last comment.
What Mike is proposing seems to be the thing missing. If that can be done to only start LiveConnect when one of the packages is first used, that would be a good solution to this problem. I believe that Mike's suggestion also fits what Patrick was refering to in his earlier comments. If that is true, then Mike would you please come up with the fix to do the lazy start of LiveConnect? With the late start of LiveConnect in place, lazy start of JVM is also done without any other code changes. Therefore, there is no need for other patch, unless you want to polish the code a bit. Talking about polishing the code, I do suggest a replacement for MaybeStartupLiveConnect(): PRBool nsJVMManager::MaybeStartupLiveConnect(void) { // If LiveConnect already started, do nothing. if (fJSJavaVM) { return PR_TRUE; } if (!IsLiveConnectEnabled()) { return PR_FALSE; } JVM_InitLCGlue(); fJSJavaVM = JSJ_ConnectToJavaVM(NULL, NULL); if (fJSJavaVM != NULL) { return PR_TRUE; } else { // Log error? return PR_FALSE; } } There is no need to call StartupJVM in MaybeStartupLiveConnect(), since JSJ_ConnectToJavaVM() eventually calls StartupJVM() if JVM has not been started. The do_while is no longer needed, and it only loop once anyway (while (0)). On the other hand, the current MaybeStartupLiveConnect() still works without any changes. The only changes needed seems to be the following two 1) Add the code that Mike is proposing, (JSJ_ResolveStandardPackage?), which calls MaybeStartupLiveConnect() when a package is first used. 2) Remove the line of code calling StartupLiveConnect(), which calls MaybeStartupLiveConnect() in the initialization of the browser, in nsJSEnvironment::nsJSEnvironment().
One additional point to consider: if an applet decides to use the JSObject API, but its page has no LiveConnect global references, we need to make sure that this also initializes LiveConnect. Perhaps when nsObjectFrame loads an applet, if its MAYSCRIPT attribute is defined, we also initialize LiveConnect.
Just to be on the safe side, Patrick, when you implement the delay startup of LiveConnect, please also consider the case of JavaScript-to-Java communitcation (e.g., document.Myapplet.doSomething() should still work), MAYSCRIPT should have covered JAVA-to-JavaScript part.
The problem with the whole JSJ_ResolveStandardPackage() approach, is that Caps defeats the whole intent in |nsSecurityNameSet::InitializeClasses()|, because it causes "netscape.security" to be resolved. My original idea, eagerly populating the global namespace with package objects for java, netscape, sun, and Packages, plus a set of sub-packages, such as netscape.security, seems to be the only practical solution to this problem. This requires splitting up LiveConnect's initialization into 2 phases, essentially predefining all of the interesting packages first, and then if properties are read from any of those predefined package, firing up Java at that point using the OJI module callbacks.
Here's an initial cut at an attempt to perform 2 phase initialization. Basically, I've delayed the full initialization of JSJavaVM objects until the first call to JSJ_AttachCurrentThreadToJava(). I haven't checked to see if this is completely bullet proof, but it does successfully defer the loading of the MRJ plugin until LiveConnect is actually running.
Taking bug.
Assignee: joe.chou → beard
Status: ASSIGNED → NEW
I was planning to switch those netscape.security calls in caps over from ScriptExternalNameSet declaration to being XPConnected objects; will this make things easier? If so, I'll make that a priority.
No, as long as you are writing ANY sort of object in to "netscape.security" there will be an impact on LiveConnect. Luckily, I've worked out a way to lazily initialize LiveConnect that should work regardless. I am seeking commentary on this patch.
Status: NEW → ASSIGNED
I have verified that it works on Linux; Java doesn't start until I load an Applet or evaluate javascript:java.lang.System. The Linux plugin does have a tendency to hang the browser however...
verified on win32, the patch builds, there's no java icon in the taskbar after we start up. When I go to a page with an applet, the icon appears and java's running. go team!!
I tried the patch on Solaris (the patch should have included the removing of the line of calling StartupLiveConnect() in nsJSEnvironment::nsJSEnvironment()), and it seemed to work ok with the cases with Applet tags. But for a case without an applet tag (see attachment below), it seemed not invoking call to Java. For example, I set a breakpoint at getContext in ProxyJNI.cpp. Without the patch (LiveConnect and JVM started at init), the breakpoint was hit, which then invoke the call method to Java plugin and JVM. With the patch, the breakpoint somehow was not hit, and no call method invoked. Is my test case valid? I might have missed something there. Attachment of the test case (simplified test case from 60018): Another test HTML (with a button): <html> <head> <title>Live Connect using a JavaObject</title> </head> <body> <form ID="form1" name=myForm> <input ID="field1" Type=text value="Live Connect using a JavaObject" name="fieldOne"> <input ID="button1" Type=button value="Call load()" name="buttonOne" onClick=click_doit()> <input ID="field2" Type=text value="Live Connect using a JavaObject" name="fieldTwo"> <input ID="button2" Type=button value="Call showAlert()" name="buttonTwo" onClick=showAlert("showAlert()")> </form> <script> function click_doit() { java.lang.System.out.println("*** calling new Cherokee() "); var htmlForm = new Packages.Cherokee("Hello"); java.lang.System.out.println("*** skip calling load() "); <!-- htmlForm.load(params); --> java.lang.System.out.println("*** calling load() done"); } function showAlert(txt) { alert ("JavaScript 'showAlert': called from " + txt); } var params = { domwin: window, domdoc: document, serverhost: "javaweb.eng.sun.com" }; java.lang.System.out.println("Starting jotest.html"); </script> </body> </html> Java code: import netscape.javascript.*; public class Cherokee { JSObject win = null; //----------------------------------------------------------------- // Constructor //----------------------------------------------------------------- public Cherokee(String txt) { System.out.println("*** Cherokee constructor: ***" + txt); } //-------------------------------------------------------------------- // Public Methods //-------------------------------------------------------------------- public void load(JSObject params) { JSObject jso; System.out.println("*** cherokee.load: Start of method ***"); if (params == null) { System.out.println("params is null"); } else { System.out.println("calling params.getMember()"); win = (JSObject) params.getMember("domwin"); if (win == null) { System.out.println("*** cherokee.load: win is null ***" ); } else { System.out.println("*** cherokee.load: win is not null ***"); } } System.out.println("*** cherokee.load: End of method ***"); } }
Sorry Joe, the patch is complete. There's no need to stop calling StartupLiveConnect() in nsJSEnvironment::nsJSEnvironment(), because Java initializes only when LiveConnect actually tries to resolve a package into a class. Please try running with only the last patch in your tree. I ran with just that on Linux and things work for me.
Patrick, you are right about no need to remove StartupLiveConnect. I tried it, and that seemed working fine. But the problem of my test case above was still there: with the patch, clicking the "Call load()" button did not call the load method, unless bringing up the Java console first, which loaded Java plugins. Without the patch, clicking the button invoked the call method. Is that a problem? Did you tested it with a case that did not have an applet tag, something similar to the Oracle case in 60018?
I tested with the URL "javascript:java.lang.System" which fires up Java. Does this simple URL work for you? I will try your test case, which may be failing for other reasons. Would you please provide a review for this patch?
Patrick, can you please attach another diff? I can't get this one to apply: D:\Projects\trunk\mozilla\js\src\liveconnect>patch -i 26516.diff jsj.c patch -i 26516.diff jsj.c patch unexpectedly ends in middle of line patch: **** Only garbage was found in the patch input.
I tried the url on my SOlaris, and I saw similar problem: if I tried to launch the url without Java plugin loaded first, nothing showed up; but if I opened the Java console first and then launch the url, I saw "[JavaClass java.lang.System]" printed on the page. I am going to tried on another trunk build on Solaris and Linux, and see how it goes.
To edburns: Patch http://bugzilla.mozilla.org/showattachment.cgi?attach_id=30892 has a weired format. Solution for unix users: -- snip -- % cat xxx.diff | tr "[\r]" "[\n]" >yyy.diff gisburn@castor/home/gisburn/tmp/moz% gpatch -p0 --dry-run <yyy.diff patching file jsj.c Hunk #1 FAILED at 449. Hunk #2 succeeded at 468 with fuzz 2. Hunk #3 succeeded at 948 (offset 253 lines). 1 out of 3 hunks FAILED -- saving rejects to file jsj.c.rej -- snip --
I've tried this on an 11pm last night Win32 trunk clobber build and I find that the plugins module is loaded at startup. However, this is the plugin code. Is your diff supposed to prevent all java related initilization, or only liveconnect related initialization? nsPluginHostImpl ctor plugins at: D:\Projects\trunk\mozilla\dist\WIN32_D.OBJ\bin\plugins plugins at: C:\Program Files\Opera\Program\Plugins For application/x-java-vm found plugin D:\Projects\trunk\mozilla\dist\WIN32_D.OBJ\bin\plugins\NPOJI600.dll
Debugging further, I find that on win32, the nsJVMManager::StartupJVM() gets called even with your patch applied. Here's the stack trace: nsJVMManager::StartupJVM() line 573 nsJVMManager::MaybeStartupLiveConnect() line 780 + 20 bytes nsJVMManager::StartupLiveConnect(nsJVMManager * const 0x0199fa58, JSRuntime * 0x010579c8, int & 0) line 128 + 11 bytes nsJSEnvironment::nsJSEnvironment() line 1505 + 49 bytes nsJSEnvironment::GetScriptingEnvironment() line 1446 + 27 bytes NS_CreateScriptContext(nsIScriptGlobalObject * 0x0197ec90, nsIScriptContext * * 0x01979240) line 1545 + 5 bytes nsDocShell::EnsureScriptEnvironment(nsDocShell * const 0x01979190) line 4439 + 50 bytes nsWebShell::GetInterface(nsWebShell * const 0x019791b4, const nsID & {...}, void * * 0x0012fbd4) line 329 + 19 bytes nsGetInterface::operator()(const nsID & {...}, void * * 0x0012fbd4) line 37 + 31 bytes nsCOMPtr<nsIDOMWindowInternal>::assign_from_helper(const nsCOMPtr_helper & {...}, const nsID & {...}) line 970 + 18 bytes nsCOMPtr<nsIDOMWindowInternal>::nsCOMPtr<nsIDOMWindowInternal>(const nsCOMPtr_helper & {...}) line 552 nsAppShellService::GetHiddenWindowAndJSContext(nsAppShellService * const 0x00aeb350, nsIDOMWindowInternal * * 0x0012fc7c, JSContext * * 0x0012fc80) line 713 + 32 bytes nsAppShellService::SetXPConnectSafeContext() line 177 + 40 bytes nsAppShellService::CreateHiddenWindow(nsAppShellService * const 0x00aeb350) line 248 main1(int 2, char * * 0x00a359b0, nsISupports * 0x00000000) line 988 main(int 2, char * * 0x00a359b0) line 1300 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1ba3c()
I tried on the load from the tip of the trunk on Solaris (built last night) and Linux (built today), found similar result: The Java JVM was started at startup (StartupJVM got called), and all the MIME types got registered. On the other hand, my previous testing was done on an OEM load on Solaris. In that case, with the patch, Java JVM was NOT started at startup time, and the url, "javascript:java.lang.System", would not work unless I opened Java console (which started JVM and loaded plugins' MIME types) first.
I concur, nsJVMManager::StartupJVM() does get called still, but, if I set a breakpoint on the MRJ plugin's MRJPlugin::StartupJVM() method, it doesn't get called until I actually do something with Java, such as a javascript: URL that references java.lang.System. Does the Sun Java plugin startup Java unconditionally or does it wait until its nsIJVMPlugin::StartupJVM() method is called?
Patrick, that patch looks ok to me, barring calls to these functions that happen even if the JavaVM has not been created/attached: JSJ_DisconnectFromJavaVM JSJ_AttachCurrentThreadToJava JSJ_DetachCurrentThreadFromJava Should these have null defenses against java_vm anyway? r/sr=brendan@mozilla.org modulo that. /be
Yeap, java_vm on Solaris would not be started till the first LiveConnect call. The patch seemed doing what it suppose to do.
ra=edburns.
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Is it possible that this fix causes a crash when going to pages with applets when the plugin is not installed and when "Java Enabled" is checked in the preferences? Should I file a new bug about this? Seen by two people on linux, CVS build from one hour ago (04/19)
When I tested the patch, I saw the crash with or without the patch. I don't think the crash is related to the patch. There is a bug about the crash leaving an applet page, and the bug number is 75070.
*** Bug 78220 has been marked as a duplicate of this bug. ***
Blocks: 78220
verified that nsJVMManager::StartupJVM() does not get called on startup anymore on trunk builds.
Status: RESOLVED → VERIFIED
wooohooo ? anyone still working on this ? atleast update the target milestone
umm ... Michael ... this bug is already fixed
ummm, just testing if you all watch out carefully *doh* *blush*
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: