Closed Bug 239857 Opened 20 years ago Closed 19 years ago

A java Plug-in call to JSObject doesn't return

Categories

(Core Graveyard :: Java: Live Connect, defect)

Product:
Core Graveyard
Component:
Java: Live Connect
Version:
1.0 Branch
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: p_samson, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

An applet accesses its HTML page via JSObject.getWindow(this) with call()
or getMember(). Sometimes it works, sometimes not. The failing method call
is not always the same. It depends on the speed of the page load.
Problem doesn't show up with the application on localhost, but with the one
installed on a DMZ. Everything is OK with IE with both servers.
Plug-in version: 1.4.2_01-b06
I can close the tabs and the browser, but still have to "end process" a
firefox.exe in the task manager.

Reproducible: Sometimes
Steps to Reproduce:
1.
2.
3.

Actual Results:  
Full thread dump Java HotSpot(TM) Client VM (1.4.2_01-b06 mixed mode):

"Thread-4709" prio=5 tid=0x02946050 nid=0x160 runnable [5eef000..5eefd98]
	at sun.plugin.javascript.navig5.JSObject.JSObjectCall(Native Method)
	at sun.plugin.javascript.navig5.JSObject.call(Unknown Source)
	at be.europeenne.euronet.contract.Select.updatePage(Select.java:458)
	at be.europeenne.euronet.contract.Select.updateResult(Select.java:585)
	at be.europeenne.euronet.contract.Select.updateResult(Select.java:467)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)
	at sun.plugin.liveconnect.SecureInvocation.access$300(Unknown Source)
	at sun.plugin.liveconnect.SecureInvocation$CallMethodThread.run(Unknown Source)

"main" prio=5 tid=0x028f33e0 nid=0x17c runnable [12e000..12faf8]
	at sun.plugin.services.WPlatformService.waitEvent(Native Method)
	at sun.plugin.services.WPlatformService.waitEvent(Unknown Source)
	at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)

[... others are normal.]
Previous report was in a scenario : JS1 -> Applet -> JS2.
Now with 1.4.2_04, it even doesn't work with IE:
you have to click-right on the icon in the task bar to allow
the browser to answer to the applet.
See http://developer.java.sun.com/developer/bugParade/bugs/4990529.html
for a similar problem.

I changed the design to cut the deadlock:
either:
 (JS1 -> Applet) initiates a new thread to run (Applet -> JS2).
or run independently:
  JS1 -> Applet
  JS1 -> JS2
 and
  Applet -> JS2

This new design works on IE. But Firefox/Mozilla still have a problem.
The JSObject.getWindow(this) in init() doesn't return.
On the brower the page is blank, with only the grey rectangle
for the applet object.
Right-click on the icon in the task bar: CPU is no more 100%, but
nothing else, and the CPU returns to 100% when you leave the menu.

Here is the trace:
----------------------------------------------------
Full thread dump Java HotSpot(TM) Client VM (1.4.2_04-b05 mixed mode):

"AWT-EventQueue-4" prio=4 tid=0x0382e270 nid=0x4c0 in Object.wait()
[2433f000..2433fd90]
	at java.lang.Object.wait(Native Method)
	- waiting on <0x100be078> (a java.awt.EventQueue)
	at java.lang.Object.wait(Unknown Source)
	at java.awt.EventQueue.getNextEvent(Unknown Source)
	- locked <0x100be078> (a java.awt.EventQueue)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

"thread applet-be.europeenne.euronet.contract.Select.class" prio=4
tid=0x0382ed70 nid=0x4ba runnable [2423f000..2423fd90]
	at sun.plugin.javascript.navig5.JSObject.JSGetNativeJSObject(Native Method)
	at sun.plugin.javascript.navig5.JSObject.JSGetNativeJSObject(Unknown Source)
	at sun.plugin.javascript.navig5.JSObject.<init>(Unknown Source)
	at sun.plugin.viewer.context.NetscapeAppletContext.getJSObject(Unknown Source)
	at netscape.javascript.JSObject.getWindow(Unknown Source)
	at be.europeenne.euronet.contract.Select.init(Select.java:367)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

If JSObject.getWindow() is moved from init() to start(), it works.

I didn't read any advice/restriction about the supported location
of JSObject calls in an applet.
Can someone point me to a reference page about this design point?

I'm moving to Java...
Component: General → Java-Implemented Plugins
Product: Firefox → Browser
Version: unspecified → 1.0 Branch
Assignee: firefox → live-connect
Component: Java-Implemented Plugins → Java: Live Connect
QA Contact: pschwartau
I think I'm seeing the same issue (my Moz becomes unreponsive and my CPU spins),
except that if I call assign JSObject.getWindow(this) from within start(), I get
a (from memory) 'com.netscape.JSObjectException', whereas if I put the call into
run() I get:

Error: [Exception... "Component returned failure code: 0x80570009
(NS_ERROR_XPC_BAD_CONVERT_JS) [nsIXPCComponents.lookupMethod]"  nsresult:
"0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame ::
chrome://communicator/content/XPCNativeWrapper.js :: anonymous :: line 91" 
data: no]
Source File: chrome://communicator/content/XPCNativeWrapper.js
Line: 91

This seems to have broken post-1.7, perhaps related to the plugin scripting
changes?: 
http://www.mozilla.org/projects/plugins/npruntime.html
This bug seems related to Bug#254801.
Test case and code at: http://kensystem.com/JSObject/
To the best of my knowledge this is an old bug in the Sun Java plugin, not a
Mozilla problem. There are other bugs on file with details, though I don't
remember enough about them to find them now. Cc:ing Kyle in case he's got more
input here.
Humbly disagreeing - if you install Moz 1.7 (or earlier) the examples work fine...
This doesnt seem to be broken anymore after some combination of variables
recently changed on my system (installed a newer nightly build, copied portions
of an old mozilla profile into a new one to solve some other problems,
un/re-installed java).

So from the few test cases I have to test against, this seems to be fixed now,
or just 'worksforme'... :-)
(In reply to comment #9)
> This doesnt seem to be broken anymore after some combination of variables
> recently changed on my system (installed a newer nightly build, copied 
portions
> of an old mozilla profile into a new one to solve some other problems,
> un/re-installed java).
> So from the few test cases I have to test against, this seems to be fixed now,
> or just 'worksforme'... :-)

i've go in this bug on 1.7.3 on windows
java applet hangs the browser (to be killed)
if the jsobject is within start method it works
even any reference to public jsobject instantiated within start would then hang 
mozilla or firefox (not IE) with same jvm on same machine, so (sensibly) it is 
not a java bug (as an example JSObject.eval).
If the call to JSObject is within init method, it would even crash the browser.
If the applet is run locally (no http), instead, it seems to be working 
flawlessly even from init(). 



This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.