Closed Bug 872969 Opened 11 years ago Closed 11 years ago

Javascript error "not a function" when calling Java Applet public methods

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Version:
21 Branch
Platform:
x86
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: m.fabbri, Assigned: gfritzsche)

References

Details

(Keywords: regression, testcase)

Attachments

(7 files)

A simple test case
1.51 KB, application/octet-stream
Details
What I use for X-Browser wait for Applet
10.69 KB, text/plain
Details
Working LiveConnect class
1.08 KB, text/plain
Details
Working minimalist HTML file
4.10 KB, text/plain
Details
The Java .class for the applet
1.51 KB, application/octet-stream
Details
Photo: - FireFox OOPP development team
43.56 KB, image/png
Details
Deny scriptable object access before SetWindow()
9.55 KB, patch
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

call Java Applet public methods from Javascript


Actual results:

Javascript Error Console return "applet.method1 is not a function"


Expected results:

I've updated Firefox from 20 to 21 version... with previous versions (<=20) works well!
Error appears only in the Mac version, Windows version don't report anything and works well!
This appears as a regression of previous reported bugs!
My code implemented with setTimeout funcion:

function signDocument(download_path) {
	if(navigator.userAgent.indexOf("MSIE")>-1) {
		signDocument_(download_path);
	}
	else {
		setTimeout(signDocument_, 100, download_path);
	}
}

function signDocument_(download_path) {
	a24.sign(download_path, "");
	flex_application.signCompleted((new String(a24.result_pknet)).toString());
	a24.result_pknet=null;
}

Javascript Error Console reports "a24.sign is not a function"!
Attach a simple testcase (or online) to the bug, please.
Flags: needinfo?(m.fabbri)
Keywords: testcase-wanted
Go to our web application demo at this link (you need Flash Player plugin and Java plugin):

http://94.82.180.69:8400/WE/index.html?server=2&username=Avvocato&password=avvocato&action=direct_login

go to section "Documenti/Documents" and press the "Firma Digitale/Digital Signature" button in the bottom area of the page... now open Javascript Error Console and you will see the error: "TypeError: a24.sign is not a function... Row: 101".
This error is activated from methods reported in comment 2... they are visible from the source of index.html page.
The workflow is Flash: "Firma Digitale/Digital Signature" button -> Javascript signDocument(download_path) method -> Java Applet a24.sign(download_path, "") -> Javascript error: "TypeError: a24.sign is not a function... Row: 101".
This happens only in Mac version of Firefox 21!
Flags: needinfo?(m.fabbri)
I tried with FF24 on Win 7, this error is not displayed, so maybe specific to OSX.

If you have some time, could you use the tool mozregression (see http://harthur.github.io/mozregression/) to find a regression range in FF21 nightlies, it would be useful.
FF21 nightlies started in Jan. 2013 (--good=2013-01-01)
Component: Untriaged → Plug-ins
Keywords: testcase-wanted → regressionwindow-wanted, testcase
Product: Firefox → Core
Flags: needinfo?(m.fabbri)
Ok I've used mozregression tool on my MacOS X (10.8.3) with Java 7u21 and this the results:

MacBook-Pro-di-mbp1:~ mbp1$ mozregression --good=2013-01-01
Downloading nightly from 2013-03-11
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): JVMLauncher.afterStart(): starting JVM process watcher
good
Downloading nightly from 2013-04-15
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): JVMLauncher.afterStart(): starting JVM process watcher
bad
Downloading nightly from 2013-03-28
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): JVMLauncher.afterStart(): starting JVM process watcher
exit
Could not kill process, could not find pid: 963, assuming it's already dead
Newest known good nightly: 2013-03-11
Oldest known bad nightly: 2013-04-15
To resume, run:
mozregression --good=2013-03-11 --bad=2013-04-15

In nightly version 2013-03-11 all works fine instead in the immediately following version 2013-04-15 appears the reported error.
Flags: needinfo?(m.fabbri)
Rerun mozregression if possible.
Why? With other parameters?
Excuse me I've noticed now the version sequence... I try immediately!
Complete mozregression results:

MacBook-Pro-di-mbp1:~ mbp1$ mozregression --good=2013-01-01
Downloading nightly from 2013-03-11
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): JVMLauncher.afterStart(): starting JVM process watcher
good
Downloading nightly from 2013-04-15
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): JVMLauncher.afterStart(): starting JVM process watcher
bad
Downloading nightly from 2013-03-28
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): JVMLauncher.afterStart(): starting JVM process watcher
bad
Downloading nightly from 2013-03-19
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): JVMLauncher.afterStart(): starting JVM process watcher
good
Downloading nightly from 2013-03-23
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): JVMLauncher.afterStart(): starting JVM process watcher
bad
Downloading nightly from 2013-03-21
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): JVMLauncher.afterStart(): starting JVM process watcher
bad
Downloading nightly from 2013-03-20
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): JVMLauncher.afterStart(): starting JVM process watcher
bad


Last good nightly: 2013-03-19
First bad nightly: 2013-03-20

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e23e43a2c14e&tochange=8156df33b757

do you want to bisect further by fetching the repository and building? (y or n) y
Building changesets:
hg not installed on this system.
MacBook-Pro-di-mbp1:~ mbp1$
(In reply to m.fabbri from comment #10)
> do you want to bisect further by fetching the repository and building? (y or
> n) y
> Building changesets:
> hg not installed on this system.

Would you be able to install Mercurial and continue there to narrow it down to a specific change?
Flags: needinfo?(m.fabbri)
Not able to reproduce this issue following STR from comment 0 comment 2 and comment 4 of Nightly (2013-03-20 and 2013-03-21) on Mac OS 10.7.5. No error found in Error Console
(In reply to m.fabbri from comment #10)

Once you have installed mercurial, here you can find more information about how to bisect and find the real causing changeset:

https://quality.mozilla.org/docs/qmo-community/lesson-plans/how-to-bisect-find-the-culprit/
(In reply to MarioMi (:MarioMi) from comment #12)
> Not able to reproduce this issue following STR from comment 0 comment 2 and
> comment 4 of Nightly (2013-03-20 and 2013-03-21) on Mac OS 10.7.5. No error
> found in Error Console

Are you able to see the Java Applet JFileChooser as result of "Firma Digitale/Digital Signature" button click?
I've tried with other MacOS X systems (10.7 and 10.8) and the error appears randomly (20% ok 80% error)... only in my MacBook Pro the error is persistent!
Can you retry more times?
Flags: needinfo?(m.fabbri)
I can see a new window in which to choose a file, but able to see any error in Console. I am actually testing this on a MiniMac so this can probably be a reason why I can't reproduce the issue.
If you see the new file chooser window it works well... Javascript calls the Applet method correctly and no errors appears in Console!
(In reply to MarioMi (:MarioMi) from comment #13)
> (In reply to m.fabbri from comment #10)
> 
> Once you have installed mercurial, here you can find more information about
> how to bisect and find the real causing changeset:
> 
> https://quality.mozilla.org/docs/qmo-community/lesson-plans/how-to-bisect-
> find-the-culprit/

As far as i know mozregression offers to do the neccessary steps when the right tools are installed, so no manual process should be needed.
(In reply to Georg Fritzsche [:gfritzsche] from comment #17)
> (In reply to MarioMi (:MarioMi) from comment #13)
> > (In reply to m.fabbri from comment #10)
> > 
> > Once you have installed mercurial, here you can find more information about
> > how to bisect and find the real causing changeset:
> > 
> > https://quality.mozilla.org/docs/qmo-community/lesson-plans/how-to-bisect-
> > find-the-culprit/
> 
> As far as i know mozregression offers to do the neccessary steps when the
> right tools are installed, so no manual process should be needed.

Yes mozregression acts any necessary actions once you've installed mercurial... I'm just a bit skeptical on build, started 15 minutes ago, that continue to report:

Building...
This build failed!
hg -R /Users/mbp1/.moz-commitbuilder-cache/mozbuild-trunk bisect --skip
Testing changeset XXX (209 changeset remaing, ~7 tests)
XXX files update, X files merged, XX files removed, X files unresolved

Building...
This build failed!
hg -R /Users/mbp1/.moz-commitbuilder-cache/mozbuild-trunk bisect --skip
Testing changeset XXX (209 changeset remaing, ~7 tests)
XXX files update, X files merged, XX files removed, X files unresolved

Building...
This build failed!
hg -R /Users/mbp1/.moz-commitbuilder-cache/mozbuild-trunk bisect --skip
Testing changeset XXX (209 changeset remaing, ~7 tests)
XXX files update, X files merged, XX files removed, X files unresolved
(In reply to Georg Fritzsche [:gfritzsche] from comment #17)

> As far as i know mozregression offers to do the neccessary steps when the
> right tools are installed, so no manual process should be needed.

True, but in the URL mentioned in Comment 14 there is a section "How to build Firefox and bisect" where are all steps needed for taking prerequisites, downloading source and build FF.
(In reply to m.fabbri from comment #18)

If you are not using ccache for building firefox, it can takes up to 1-2hours defends of PC configuration. It's a long process but don't worry those fails are excepted, not all source can be built so it takes only the source that are prepared to be built so you can receive a full correctly build.
Build error:

...
date:        Tue Mar 19 13:03:07 2013 -0700
summary:     Bug 837292 - Part 4: Followup to unbust part 2; r=rnewman

changeset:   125442:59e0077b1975
user:        Gregory Szorc <gps@mozilla.com>
date:        Tue Mar 19 13:03:24 2013 -0700
summary:     Bug 850450 - Longitudinal recording of build ID in FHR; r=rnewman

changeset:   125443:8156df33b757
parent:      125442:59e0077b1975
parent:      125437:126563fd3ba1
user:        Gregory Szorc <gps@mozilla.com>
date:        Tue Mar 19 16:37:52 2013 -0700
summary:     Merge mozilla-central into services-central
Exception RuntimeError: RuntimeError('maximum recursion depth exceeded in __instancecheck__',) in <module 'threading' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.pyc'> ignored
Nonzero exit code from ['hg', '-R', '/Users/mbp1/.moz-commitbuilder-cache/mozbuild-trunk', 'id', '-i']

Traceback (most recent call last):
  File "/usr/local/bin/mozregression", line 8, in <module>
    load_entry_point('mozregression==0.6.4', 'console_scripts', 'mozregression')()
  File "build/bdist.macosx-10.8-intel/egg/mozregression/regression.py", line 187, in cli
  File "build/bdist.macosx-10.8-intel/egg/mozregression/regression.py", line 105, in bisect
  File "build/bdist.macosx-10.8-intel/egg/mozregression/regression.py", line 96, in printRange
  File "build/bdist.macosx-10.8-intel/egg/mozregression/regression.py", line 87, in build
  File "build/bdist.macosx-10.8-intel/egg/mozregression/regression.py", line 81, in findRegressionChset
  File "/Library/Python/2.7/site-packages/mozcommitbuilder-0.4.11-py2.7.egg/mozcommitbuilder/builder.py", line 304, in bisect
    self.bisectRecurse(testcondition=testcondition, args_for_condition=args_for_condition)
  File "/Library/Python/2.7/site-packages/mozcommitbuilder-0.4.11-py2.7.egg/mozcommitbuilder/builder.py", line 461, in bisectRecurse
    self.bisectRecurse(testcondition=testcondition, args_for_condition=args_for_condition)
  File "/Library/Python/2.7/site-packages/mozcommitbuilder-0.4.11-py2.7.egg/mozcommitbuilder/builder.py", line 461, in bisectRecurse
    self.bisectRecurse(testcondition=testcondition, args_for_condition=args_for_condition)
...
We've been experiencing the same issue with our application.  It looks like this commit could be causing the problem:

http://hg.mozilla.org/mozilla-central/rev/9c6474e8d3c8

When it doesn't work, we get log traces that look like:
.
.
.
AbstractPlugin.getScriptingObjectForApplet(null) returning 0x0 because applet is not running
AbstractPlugin.getScriptingObjectForApplet(null) returning 0x0 because applet is not running
Failed to call JS!
MozillaPlugin.setWindow sun.plugin2.main.server.MozillaPlugin@7559f3f0 hWndControlWindow = -1 caRenderServerName = com.apple.java.jrs.carenderserver-86840
MozillaPlugin.setWindow sun.plugin2.main.server.MozillaPlugin@7559f3f0 hWndControlWindow = -1 caRenderServerName = com.apple.java.jrs.carenderserver-86840
.
.
.

But when it occasionally did work, we saw:
.
.
.
MozillaPlugin.setWindow sun.plugin2.main.server.MozillaPlugin@7559f3f0 hWndControlWindow = -1 caRenderServerName = com.apple.java.jrs.carenderserver-86900
MozillaPlugin.setWindow sun.plugin2.main.server.MozillaPlugin@7559f3f0 hWndControlWindow = -1 caRenderServerName = com.apple.java.jrs.carenderserver-86900
.
.
.
AbstractPlugin.getScriptingObjectForApplet starting to wait for result ID 1
AbstractPlugin.getScriptingObjectForApplet starting to wait for result ID 1
.
.
.


From http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/plugin2/main/server/MozillaPlugin.java.html
and
http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/plugin2/main/server/AbstractPlugin.java.html , this seems to happen because the call to setWindow was delayed until after the call to getScriptingObjectForApplet.

We only see the problem when we are injecting the <object> tag via JavaScript after page load.  Additionally, adding a 5 second sleep before returning from the JavaScript function that wrote the <object> seemed to help.
(In reply to will from comment #22)
> We only see the problem when we are injecting the <object> tag via
> JavaScript after page load.  Additionally, adding a 5 second sleep before
> returning from the JavaScript function that wrote the <object> seemed to
> help.

Does inserting a |object.clientTop;| line before attempting to script the object help? That should force a layout flush and possibly ensure SetWindow is called before trying to talk to the plugin.
Adding the clientTop line didn't help. I also tested putting a breakpoint on the one line where we call into the applet and didn't let it execute.  The logs still showed the improper ordering of setWindow and getScriptingObject occurring long before that.  Here's the start of the log from that run:

NativeLibLoader: /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/lib/libnpjp2.dylib doesn't exist
NativeLibLoader: trying to load /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/libnpjp2.dylib
  (Succeeded)
Failed to call JS!
MozillaPlugin.MozillaPlugin with browser thread ID: 140735086457216
MozillaPlugin.MozillaPlugin with browser thread ID: 140735086457216
Failed to call JS!
MozillaPlugin.useCARendering sun.plugin2.main.server.MozillaPlugin@3a18cecd hWndControlWindow = -1 serverName = com.apple.java.jrs.carenderserver-2785
MozillaPlugin.useCARendering sun.plugin2.main.server.MozillaPlugin@3a18cecd hWndControlWindow = -1 serverName = com.apple.java.jrs.carenderserver-2785
MozillaPlugin: JavaScript error: Applet is not running
MozillaPlugin: JavaScript error: Applet is not running
AbstractPlugin.getScriptingObjectForApplet(null) returning 0x0 because applet is not running
AbstractPlugin.getScriptingObjectForApplet(null) returning 0x0 because applet is not running
Failed to call JS!
MozillaPlugin.setWindow sun.plugin2.main.server.MozillaPlugin@3a18cecd hWndControlWindow = -1 caRenderServerName = com.apple.java.jrs.carenderserver-2785
MozillaPlugin.setWindow sun.plugin2.main.server.MozillaPlugin@3a18cecd hWndControlWindow = -1 caRenderServerName = com.apple.java.jrs.carenderserver-2785
Failed to call JS!
  Attempting to start applet
  Attempting to start applet
2013-05-22 14:59:06.225 plugin-container[2785:651f] Starting autoupdate check.
2013-05-22 14:59:06.229 plugin-container[2785:651f] About to launch file://localhost/Library/Internet%20Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/Java%20Updater.app/
Failed to call JS!
JVMLauncher.start: launcher params:
JVMLauncher.start: launcher params:
Failed to call JS!
    <-Xbootclasspath/a:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/javaws.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/plugin.jar>
    <-Xbootclasspath/a:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/javaws.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/plugin.jar>
Tentatively, it seems like we got to the bottom of it.  getScriptingObjectForApplet is called not when you first make a function call, but when you fetch the element from the DOM.  We were calling |this.applet = document.getElementById('my-app');| immediately after appending the <object>.

As a workaround, we refactored to lazily fetch the element from the DOM later. We also wrapped our calls to |this.applet.api();| in a setTimeout to make sure they were never called without first giving setWindow a chance to run. m.fabbri@softlab.it, a similar workaround could probably work with your application, at a glance.

If you need any more information about how we reproduced this problem, let me know.  We boiled it down to a very simple sandbox application in our testing.
Thanks Will, SOLVED!!!

The workaround is not to draw any applet reference immediately after the Java Applet deployment... if I leave time to call setWindow method it works!
In short this was my old index.html code:

<!DOCTYPE html>
<html>
	<head>
		<title>WE</title>
		<meta http-equiv="content-type" content="text/html; charset=UTF-8">
		<style type="text/css">html {width: 100%; height: 100%;} body {width: 100%; height: 100%; margin: 0; padding: 0; overflow: hidden;}</style>
		<script type="text/javascript" src="javascript/deployJava.js"></script>
		<script type="text/javascript">
			var a24; /*** BAD ***/

			function downloadDocument(document_path, directory_predefinita) {
				if(navigator.userAgent.indexOf("MSIE")>-1) {
					downloadDocument_(document_path, directory_predefinita);
				}
				else {
					setTimeout(downloadDocument_, 1, document_path, directory_predefinita);
				}
			}

			function downloadDocument_(document_path, directory_predefinita) {
				a24.download(document_path, directory_predefinita);
				flex_application.downloadCompleted((new String(a24.result_download)).toString());
				a24.result_download=null;
			}

			function signDocument(download_path) {
				if(navigator.userAgent.indexOf("MSIE")>-1) {
					signDocument_(download_path);
				}
				else {
					setTimeout(signDocument_, 1, download_path);
				}
			}

			function signDocument_(download_path) {
				a24.sign(download_path, "");
				flex_application.signCompleted((new String(a24.result_pknet)).toString());
				a24.result_pknet=null;
			}

...

		</script>
	</head>
	<body>
		<script type="text/javascript">
			if(navigator.userAgent.indexOf("MSIE")>-1) {
				document.write("<object id='flex_application' classid='clsid:D27CDB6E-AE6D-11CF-96B8-444553540000' style='width: 100%; height: 100%;'><param name='movie' value='index.swf'/><param name='flashVars' value='" + location.search.substring(1) + "'/></object>");
			}
			else {
				document.write("<object id='flex_application' classid='clsid:D27CDB6E-AE6D-11CF-96B8-444553540000' style='width: 100%; height: 100%;'><embed type='application/x-shockwave-flash' src='index.swf' flashVars='" + location.search.substring(1) + "' style='width: 100%; height: 100%;'/></object>");
			}
			deployJava.runApplet({id: "applet_24", code: "elwe.applet.Applet24.class", archive: "elwe.jar, pknetj.jar", width: 100, height: 100}, {separate_jvm: true}, "1.6");
			var a24=document.getElementById("applet_24"); /*** BAD ***/
		</script>
	</body>
</html>

My new code:

<!DOCTYPE html>
<html>
	<head>
		<title>WE</title>
		<meta http-equiv="content-type" content="text/html; charset=UTF-8">
		<style type="text/css">html {width: 100%; height: 100%;} body {width: 100%; height: 100%; margin: 0; padding: 0; overflow: hidden;}</style>
		<script type="text/javascript" src="javascript/deployJava.js"></script>
		<script type="text/javascript">
			function downloadDocument(document_path, directory_predefinita) {
				if(navigator.userAgent.indexOf("MSIE")>-1) {
					downloadDocument_(document_path, directory_predefinita);
				}
				else {
					setTimeout(downloadDocument_, 1, document_path, directory_predefinita);
				}
			}

			function downloadDocument_(document_path, directory_predefinita) {
				var a24=document.getElementById("applet_24"); /*** GOOD ***/
				a24.download(document_path, directory_predefinita);
				flex_application.downloadCompleted((new String(a24.result_download)).toString());
				a24.result_download=null;
			}

			function signDocument(download_path) {
				if(navigator.userAgent.indexOf("MSIE")>-1) {
					signDocument_(download_path);
				}
				else {
					setTimeout(signDocument_, 1, download_path);
				}
			}

			function signDocument_(download_path) {
				var a24=document.getElementById("applet_24"); /*** GOOD ***/
				a24.sign(download_path, "");
				flex_application.signCompleted((new String(a24.result_pknet)).toString());
				a24.result_pknet=null;
			}

...

		</script>
	</head>
	<body>
		<script type="text/javascript">
			if(navigator.userAgent.indexOf("MSIE")>-1) {
				document.write("<object id='flex_application' classid='clsid:D27CDB6E-AE6D-11CF-96B8-444553540000' style='width: 100%; height: 100%;'><param name='movie' value='index.swf'/><param name='flashVars' value='" + location.search.substring(1) + "'/></object>");
			}
			else {
				document.write("<object id='flex_application' classid='clsid:D27CDB6E-AE6D-11CF-96B8-444553540000' style='width: 100%; height: 100%;'><embed type='application/x-shockwave-flash' src='index.swf' flashVars='" + location.search.substring(1) + "' style='width: 100%; height: 100%;'/></object>");
			}
			deployJava.runApplet({id: "applet_24", code: "elwe.applet.Applet24.class", archive: "elwe.jar, pknetj.jar", width: 100, height: 100}, {separate_jvm: true}, "1.6");
		</script>
	</body>
</html>

As also suggested by Will is good practice wraps any Java Applet method calls in a setTimeout function.
This in my opinion is still an error but with this workaround Firefox have the time to instantiate everything it needs... can I change status to RESOLVED?
Thanks to all!
Let's see first if we can fix this, we shouldn't break previously working behavior.

So this might specifically be a side-effect of bug 823559. Does it work fine if you go to about:config and add a new boolean named "dom.ipc.plugins.java.enabled" with it's value set to true?
Status: UNCONFIRMED → NEW
Ever confirmed: true
No, it don't work fine with dom.ipc.plugins.java.enabled=true.
(In reply to m.fabbri from comment #28)
> No, it don't work fine with dom.ipc.plugins.java.enabled=true.

Sorry, my bad - i meant setting it to "false".
(In reply to will from comment #25)
> If you need any more information about how we reproduced this problem, let
> me know.  We boiled it down to a very simple sandbox application in our
> testing.

Could you provide a small, self-contained test-case as an attachment here?
Yes, with dom.ipc.plugins.java.enabled=false it works!!!
Thanks for checking.

So - maybe we request the scriptable object from the plugin earlier for some reason when it's running out-of-process.
Assignee: nobody → georg.fritzsche
Blocks: 823559
Keywords: regressionwindow-wanted → regression
Priority: -- → P2
As a test case you can use Oracles example for accessing a Java Applet from Javascript: http://docs.oracle.com/javase/tutorial/deployment/applet/examples/dist/applet_InvokingAppletMethodsFromJavaScript/AppletPage.html

Open the console, run the example and you will see an error: "TypeError: mathApplet.Packages is undefined"

Placing a break point there, you can play around. E.g. try to access the methods defined in the Applet. The example is documented at: http://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html
Attached file A simple test case — 

    
    

    
  
I have a similar problem (only verified on Mac OS X, but haven't ruled out other OS yet), but slightly different trigger conditions it seems. I get the problem both with and without inserting the applet into the dom via script. I have an example here where the applet is included directly in the initial html:

http://chesstempo.com/test/bad-liveconnect.html

You'll need to look at the console to see what is going on, here is the important part of the applet initialisation code:
function checkApplets2() {

  console.log("check applets");
  var ca = document.getElementById('chessApplet');
  //ca:[object HTMLAppletElement] inst:function typeof isActive:undefined id:chessApplet
  
  console.log("ca:"+ca+" inst:"+(typeof ca)+" typeof isActive:"+typeof(ca.isActive)+" id:"+ca.id);
  // Check that we found our applet in the DOM and that it had an isActive function and isActive returned true
  if (!ca || (ca.id!="chessApplet") || (typeof ca.isActive == 'undefined') || !ca.isActive())
    {
      
      // Could not find initialised applet so wait 1 second and try again
      window.timerId = setTimeout(checkApplets2, 1000);
      return;
    }

    if (window.timerId) {
      clearTimeout(window.timerId);
    }

    // Applet initialised ok
    compLoaded();
 
}


   contentLoaded(window,
                 function (e)
                 {
                   setTimeout(checkApplets2,1);
                 });

contentLoaded is a cross browser wrapper for the DOMContentLoaded event. When it triggers we start looking for our applet and wait for isActive to return true on it.

When this code is run with dom.ipc.plugins.java.enabled=false the applet initialises fine returning the following debug on the console:
ca:[object HTMLAppletElement] inst:function typeof isActive:function id:chessApplet

I.e. isActive is a function on the applet object right from the first call.

However when dom.ipc.plugins.java.enabled=true

The applet object is defined, but never gets a defined isActive function so keeps looping printing:
ca:[object HTMLAppletElement] inst:function typeof isActive:undefined id:chessApplet

I haven't been able to find a workaround that works for me yet (other than asking mac users to either downgrade to Firefox 20, or manually hack their config with the dom.ipc.plugins.java.enabled=false setting, neither of which is ideal. So I hope Georg might be able to find a fix for this, I'd also be very open to suggestions on other workarounds I could try :-)

Let me know if you have more questions. Perhaps my applet itself is where I need to look for a workaround, rather than the javascript.

Cross-browser liveconnect has been a bit of a nightmare (Firefox up till now has behaved better than most browsers, but I have hacks in place to deal with most browser's idiosyncrasies in this area). Unfortunately there really are no good in-browser alternatives for some of the things it can do (without turning to flash/silverlight, and while Java 7's security model has taken a bit of beating lately, Flash has been worse when you consider the entire history of both technologies). 

Regards,
Richard.

    
    

    
  


  
Needs Java 7 but seems to work for me.

Not sure that I completely understand your problem but it rings a bell.

"waitForAppletDOM" is the bit that could/may be relevant.

Cheers Richard Maher

    
    

    
  
Thanks Richard,

I like the use of the applet status flag, but it looks like this will have the same issue for me as my isActice() check. Putting the equivalent check in my code shows similar behaviour. With dom.ipc.plugins.java.enabled=true  the "chan.status" test plunked into my checkApplets2() function (my equivalent to your "watiForAppletDOM") is always undefined. As soon as I set dom.ipc.plugins.java.enabled to false, chan.status is returning 2 indicating the applet loaded fine (as the isActive test I'm using succeeds). 

Is your code currently working for you with your applet in Firefox 21 on Mac OS X. If so , then timing issues specific to the initialisation of my particular applet may be the issue, rather than a problem with the javascript side.

    
    

    
  
(In reply to jonesr from comment #37)

Hi Richard,

I don't have OS/X at home but if you were to turn the Web Console on I would expect to see something similar to Windows 7: -

[20:04:32.523] The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol. @ http://127.0.0.1/randomator.html
[20:04:33.628] going for wait
[20:04:33.628] in waitForAppletDOM type of status is number
[20:04:33.628] case 1
[20:04:33.628] case 0
[20:04:33.889] in waitForAppletDOM type of status is number
[20:04:33.890] case 1
[20:04:33.890] case 0
[20:04:34.137] in waitForAppletDOM type of status is number
[20:04:34.138] case 1
[20:04:34.138] case 0
[20:04:34.401] in waitForAppletDOM type of status is number
[20:04:34.401] case 1
[20:04:34.401] case 0
[20:04:34.651] in waitForAppletDOM type of status is number
[20:04:34.652] case 1
[20:04:34.652] case 0
[20:04:34.906] in waitForAppletDOM type of status is number
[20:04:34.906] case 1
[20:04:34.906] case 0
[20:04:35.180] in waitForAppletDOM type of status is number
[20:04:35.180] case 1
[20:04:35.181] case 0
[20:04:35.430] in waitForAppletDOM type of status is number
[20:04:35.430] case 1
[20:04:35.430] case 0
[20:04:35.680] in waitForAppletDOM type of status is number
[20:04:35.680] case 1
[20:04:35.680] case 0
[20:04:35.930] in waitForAppletDOM type of status is number
[20:04:35.930] case 1
[20:04:35.930] case 0
[20:04:36.179] in waitForAppletDOM type of status is number
[20:04:36.179] case 1
[20:04:36.179] case 0
[20:04:36.429] in waitForAppletDOM type of status is number
[20:04:36.429] case 1
[20:04:36.429] case 0
[20:04:36.678] in waitForAppletDOM type of status is number
[20:04:36.678] case 1
[20:04:36.678] case 0
[20:04:36.928] in waitForAppletDOM type of status is number
[20:04:36.928] case 1
[20:04:36.928] case 0
[20:04:37.177] in waitForAppletDOM type of status is number
[20:04:37.177] case 1
[20:04:37.177] case 0
[20:04:37.427] in waitForAppletDOM type of status is number
[20:04:37.427] case 1
[20:04:37.427] case 0
[20:04:37.676] in waitForAppletDOM type of status is number
[20:04:37.676] case 1
[20:04:37.677] case 0
[20:04:37.926] in waitForAppletDOM type of status is number
[20:04:37.926] case 1
[20:04:37.926] case 0
[20:04:38.175] in waitForAppletDOM type of status is number
[20:04:38.176] case 1
[20:04:38.176] case 0
[20:04:38.425] in waitForAppletDOM type of status is number
[20:04:38.425] case 1
[20:04:38.425] case 0
[20:04:38.675] in waitForAppletDOM type of status is number
[20:04:38.675] case 1
[20:04:38.675] case 0
[20:04:38.924] in waitForAppletDOM type of status is number
[20:04:38.924] case 1
[20:04:38.925] case 0
[20:04:39.174] in waitForAppletDOM type of status is number
[20:04:39.174] case 1
[20:04:39.174] case 0
[20:04:39.424] in waitForAppletDOM type of status is number
[20:04:39.424] case 1
[20:04:39.424] case 0
[20:04:39.674] in waitForAppletDOM type of status is number
[20:04:39.674] case 1
[20:04:39.674] case 0
[20:04:39.838] in onLoad status is 2
[20:04:39.939] in waitForAppletDOM type of status is number
[20:04:39.939] case 2
[20:04:39.940] in onLoad status is 2

My Friday nights rock!

Cheers Richard Maher

    
    

    
  
Thanks Richard,

Based on the original bug reporter, it sounds like this might be Mac OS X specific. Based on what I see of the status flag in my own tests, the status would never become defined on Mac OS X using my own applet, so I'd be interested to know what happens for you when you can try this at work on a Mac with FF 21. Status only reliably changes to 2 for me when adding the config that turns of the out-of-process plugin execution.

There appears to be some timing factor in play here as I've seen it work correctly once (out of about 20-30 tries, so like the original reporter, on a macbook pro, it is very reliably reproducible, may not be the case on other macs).

Regards,
Richard.

    
    

    
  
So if Java expects an initial SetWindow message before being scripted, but also sometimes crashes if it gets SetWindow while inside a NPN call (bug 831768), there is no way I can see to 100% work around both quirks. We can try checking if we're inside a NPN call when a plugin is scripted, and flush pending SetWindows first if not, but it would still be possible to do re-entrant things like calling java code that calls javascript that spawns a new plugin and tries to script it -- unless the JRE fixes one bug or the other, I'm not sure we can fix that.

On a side note, the current HTML5 spec does not provide any guarantees for spawning plugins synchronously (e.g. adding it to the DOM and immediately scripting it), and all browsers handle this slightly differently. Additionally, things like click-to-play might make the plugin spawn much later (after a user okays it). Ideally, then, the best way to talk with a plugin would be to add it to the document and have it send a callback to JS when it's ready and loaded.

Another random thought: Perhaps the re-entrant SetWindow java crashes don't happen for the initial SetWindow call? We could try unconditionally flushing SetWindow on the first script request for java plugins and see if the crashes from 831768 re-appear.
Blocks: 831768

    
    

    
  
Two things that might not help here (and I could be in the same boat on Monday) but you MUST do: -

1) Set the init() method as synchronized. Not sure which browser it was but I have seen with my own eyes (check comp.lang.java.programmer somewhere for ref) that my isAuthorized()/isDone() or the isActive() methods running half way through the execution of init(). As evidenced via Java console log output.

2) (I think this was for IE) Create the DIV and append it to the document.body BEFORE setting the innerHTML.

Cheers Richard

    
    

    
  
John: In my case the window object appears to be set, but I'm still not seeing the applet methods show up from the javascript side. For example in my applet init() I have this debug code:
 win = JSObject.getWindow(this);

   System.out.println("set win:"+win);

With the output:
set win:[object Window]

Suggesting the window is set, and after this I'm cycling around on the javascript side waiting for the isActice function to be available on the applet, but it never arrives. Do you think the fixes in 831768 might be causing the problem I'm seeing?

richard: Making init synchronized is a good suggestion, as is something I'll do , but it isn't the problem here, as I'm not making calls on the applet from javascript until the isActive function/method shows up, which it doesn't. Also, my test case isn't scripting the applet creation, but relying on a standard <applet> tag pre-existing in the initial page HTML, so order of operations for the applet/object setup are not relevant yet (I do have production code that has to do this, but that isn't relevant to the current test case). I do have some things I can revisit in my init path though, which might be exasperating the current problem, for example I have static initialisers, and threads that are launched from my init. I could probably avoid both, which will change the timing profile of the code which might help make it "magically" work.

    
    

    
  
(In reply to jonesr from comment #42)
> John: In my case the window object appears to be set, but I'm still not
> seeing the applet methods show up from the javascript side. For example in
> my applet init() I have this debug code:
>  win = JSObject.getWindow(this);
> 

Again, it might not be relevant to yor case but, in a given set of circumstances/browsers it is this very call (in line with documented applet thread behaviour) which will set your Javascript back in motion and call your isActive() method before applet initialization is complete.

>    System.out.println("set win:"+win);
> 
> With the output:
> set win:[object Window]
> 
> Suggesting the window is set, and after this I'm cycling around on the
> javascript side waiting for the isActice function to be available on the
> applet, but it never arrives. Do you think the fixes in 831768 might be
> causing the problem I'm seeing?
> 
> richard: Making init synchronized is a good suggestion, as is something I'll
> do , but it isn't the problem here, as I'm not making calls on the applet
> from javascript until the isActive function/method shows up, 

Isn't isActive() a call from JavaScript to Java? Have you overridden it? Is it to synchronized?

For the sake of wasting 10mins may I suggest making init() synchronized, overwriding isActive (or better still your own isDone() method) and synchronizing it and sprinkling a whole lot of system.out.printlnS and see what happens.


>which it
> doesn't. Also, my test case isn't scripting the applet creation, but relying
> on a standard <applet> tag pre-existing in the initial page HTML, so order
> of operations for the applet/object setup are not relevant yet (I do have
> production code that has to do this, but that isn't relevant to the current
> test case). I do have some things I can revisit in my init path though,
> which might be exasperating the current problem, for example I have static
> initialisers, and threads that are launched from my init. I could probably
> avoid both, which will change the timing profile of the code which might
> help make it "magically" work.

Dynamic run-time discovery of Applets is IMHO so much more useful and functionally appealing.

Throw in the                         {"name":"java_status_events","value":"true"          },
and my waitForAppletDOM
and what could go wrong :-)

    
    

    
  
(In reply to Richard Maher from comment #43)
> (In reply to jonesr from comment #42)
> > John: In my case the window object appears to be set, but I'm still not
> > seeing the applet methods show up from the javascript side. For example in
> > my applet init() I have this debug code:
> >  win = JSObject.getWindow(this);
> > 
> 
> Again, it might not be relevant to yor case but, in a given set of
> circumstances/browsers it is this very call (in line with documented applet
> thread behaviour) which will set your Javascript back in motion and call
> your isActive() method before applet initialization is complete.
> 

I never call isActive in my failure case, the check to see if the applet is ready to use looks like this:
 if (!ca || (ca.id!="chessApplet") || (typeof ca.isActive == 'undefined') || !ca.isActive())
    {

       // not ready
    }
    else
    {

       // ready
    }
I have debug output that shows that isActive isn't called here because typeof ca.isActive == 'undefined' always seems to be true, i.e. the isActive is always undefined, and never made available, if I tried to call it, I'd end up with "not a function" errors, which is the title of this bug.


> >    System.out.println("set win:"+win);
> > 
> > With the output:
> > set win:[object Window]
> > 
> > Suggesting the window is set, and after this I'm cycling around on the
> > javascript side waiting for the isActice function to be available on the
> > applet, but it never arrives. Do you think the fixes in 831768 might be
> > causing the problem I'm seeing?
> > 
> > richard: Making init synchronized is a good suggestion, as is something I'll
> > do , but it isn't the problem here, as I'm not making calls on the applet
> > from javascript until the isActive function/method shows up, 
> 
> Isn't isActive() a call from JavaScript to Java? Have you overridden it? Is
> it to synchronized?
> 
> For the sake of wasting 10mins may I suggest making init() synchronized,
> overwriding isActive (or better still your own isDone() method) and
> synchronizing it and sprinkling a whole lot of system.out.printlnS and see
> what happens.
> 

I can try that, but the previous check indicates that isActive and isDone will remain undefined, and I'll be unable to call them. If I'm not calling them (which is the case now), I'm not sure how init() being synchronized will help, unless it magically makes isActive become defined, but you're right it might be worth a go, especially as I have other threads being launched, and it might change some other behaviour that isn't obvious to me right now.


> 
> >which it
> > doesn't. Also, my test case isn't scripting the applet creation, but relying
> > on a standard <applet> tag pre-existing in the initial page HTML, so order
> > of operations for the applet/object setup are not relevant yet (I do have
> > production code that has to do this, but that isn't relevant to the current
> > test case). I do have some things I can revisit in my init path though,
> > which might be exasperating the current problem, for example I have static
> > initialisers, and threads that are launched from my init. I could probably
> > avoid both, which will change the timing profile of the code which might
> > help make it "magically" work.
> 
> Dynamic run-time discovery of Applets is IMHO so much more useful and
> functionally appealing.
> 
> Throw in the                        
> {"name":"java_status_events","value":"true"          },
> and my waitForAppletDOM
> and what could go wrong :-)

As mentioned earlier, I added that and the relevant code checking for the status flag (i.e. the same check as your code in waitForAppleDom). It ended up yielding similar results to my existing checks for applet availability. For my applet, the status flag never ends up getting defined, just like isActive never gets defined. If I switch off the out-of-process flag as suggested earlier by George it works (i.e. the status flag returns results similar to what you log shown above is showing, and the isActive method becomes defined).

Regards,
Richard.

    
    

    
  
Hi Richard,

Can you please attach a SSCCE with the static "applet" tag and the JSObject.getwindow call to help eliminate the unknow unknowns? I might not be able to help but I am very interested!

What you are talking here is Aplles and Fish let alone oranges :-)

Cheers Richard

    
    

    
  
BTW Is there any particular ewason you are persisting with the Applet tag when it is no longer supported in HTML5?

<object>'s good.

    
    

    
  
I've updated my original test page to include a very minimal applet, same url:
http://chesstempo.com/test/bad-liveconnect.html
The applet code is available here:
http://chesstempo.com/test/LiveConnect.java

and looks like this:

import netscape.javascript.*;
import java.applet.Applet;
import java.awt.*;
import java.io.*;
import java.util.concurrent.*;

public class LiveConnect extends Applet  {

  public JSObject win = null;

public synchronized void init() {


try
 {
   System.out.println("init called");
   
   win = JSObject.getWindow(this);

   System.out.println("set win:"+win);

   System.out.println("init finished");
   
 }
 catch(Exception e)
 {
   StringWriter sw = new StringWriter();
   e.printStackTrace(new PrintWriter(sw));
   String stacktrace = sw.toString();
   System.out.println("Error on init:"+stacktrace);
   //win.call("initError",new Object[] { stacktrace });
 }
}
 
 public void destroy()
 {
   System.out.println("destroy");
 }


  public void stop()
  {

    System.out.println("stop");
  }


  public void start() 
  {
    System.out.println("start");
  }


}



As expected synchronizing init makes no difference. This simplified example also fails to initialising. Turning on java_status_events and looking at the status shows the status as undefined, as is the isActive function.

As suggested by Georg adding the follow config set in about:config :
dom.ipc.plugins.java.enabled
and setting it to false and then restarting the rebrowser suddenly makes the whole thing work (i.e. looking at the console output shows the applet is detected as initialised, with that config setting set to true, the code loops around for ever waiting for isActive/status to become defined).

I use applet simply because that is what I got working across the widest range of browsers, at the time I was coding this. I might have done as well with object, but from memory there were some platforms where this didn't work as well. I assume it probably does now across all the browsers I care about, and I should probably look at updating.

Regards,
Richard.

    
    

    
  


  
A modified version of Richard's Applet

    
    

    
  


  
Seems to work for me. What happens for you? Have I mis-understood?

    
    

    
  


  
Sorry, the other file is the java source and this is the Applet's class file for those who don't wish to compile.

    
    

    
  
Hi Richard,

Your modified class does not work for me, and your HTML does not work with your modified class either.  They fail in exactly the same way that my original class and javascript equivalent of waitForAppletDOM fails.  The chan.status is never defined. This doesn't surprise me, as things like synchronizing init and checking for chan.status instsead of chan.isActive do not address the core issue which is that nothing useful is defined on the applet , not matter how long I wait. Synchronizing isn't likely to change this as I never actually make any calls on the applet from my end, as there is nothing defined to make calls on!

I noticed you haven't tested my sample page, and I wonder if it also works for you. Which firefox version, operating system version and hardware platform is this working on for you? I now have three versions for testing on my page:

First my simple applet with my own "wait for applet to appear code":
http://chesstempo.com/test/bad-liveconnect.html

Your version of my simple applet, but still with my own "wait for applet to appear code":
http://chesstempo.com/test/bad-liveconnect2.html

and lastly Your version of my simple applet with your "wait for applet" (i.e. waitForAppletDOM) code (i.e. pretty much what you are testing on, but running on my server):
http://chesstempo.com/test/bad-liveconnect3.html

Based on the fact that the last version works for you, I suspect that if you test on the same platform that this works, that my original version will likely work for you too, and that differences in operating system or hardware platform are creating a difference.

    
    

    
  
OK I'll run your code tomorrow and report back versions etc. (Certainly FF 21 and OS/X something) but perhaps more importantly the latest Java version. Are you sure you're run Java 7.21 as verified at www.java.com?

Anyway I'd better free up more bandwidth for the mozilla experts.

Cheers Richard

    
    

    
  
Yes, according to the java console launched when the applet starts I'm running java 7 21:
Using JRE version 1.7.0_21-b12

Regards,
Richard.

    
    

    
  
I'd love to see your results on the original code, as if it works for you it would at least help isolate the platform, one of the earlier reporters mentioned they had more trouble reproducing on apple hardware other than their Macbook pro (which is what I'm using), while the Macbook was very reliably producing the issue.

Richard.

    
    

    
  
Bizarre! These results don't make a lot of sense (at least to me) so I suggest you get a lot more feedback from different versions but on the two iMacs here one works and the other doesn't both FF 21.0 both Java 7.0_21b12.

OS/X 10.7.5 works and 10.8.3 doesn't I suspect some other forces at play but FWIW that's what I saw. (Your code and mine)

Cheers Richard.

PS. It may not be much use to you, but I assure you that for those scripting Applets, using LiveConnect, and dynamically loading Applets at runtime, the quirks and redundancy and duplication in my script are absolutely necessary!

    
    

    
  
Thanks Richard.

It is reassuring to hear that both code examples are breaking on a machine other than mine :-) Hopefully whatever has changed here in FF 21 is something that can be fixed without having to get Oracle to fix anything at their end (even if the core problem is there), given FF 20 seems to have had something that at least worked for this case on the impacted platform (apparently recent Mac OS X versions).

    
    

    
  
(In reply to John Schoenick [:johns] from comment #40)
> Ideally, then, the best way to talk with a
> plugin would be to add it to the document and have it send a callback to JS
> when it's ready and loaded.

Right, but from what i see, when doing:
> var p = document.getElementById('applet');
... we immediately request the scriptable object, even if the actual scripting happens much later. I wonder if we couldn't retrieve it when actual
scripting occurs on a proxy object to reduce such problems - which might help if we were to make plugin instantiation async.
 
> Another random thought: Perhaps the re-entrant SetWindow java crashes don't
> happen for the initial SetWindow call? We could try unconditionally flushing
> SetWindow on the first script request for java plugins and see if the
> crashes from 831768 re-appear.

I'll check into this later, thanks.

    
    

    
  
(In reply to jonesr from comment #42)
> John: In my case the window object appears to be set, but I'm still not
> seeing the applet methods show up from the javascript side.

From comment 22 it looks like if the applet isn't ready when we originally ask it for a scripting context, it will return null, and the applet tag will never get the plugin inserted into its protochain -- so only when the first script access occurs is the window relevant. This can occur in scenarios you wouldn't expect, such as calling getElementById.

(In reply to jonesr from comment #47)
> I use applet simply because that is what I got working across the widest
> range of browsers, at the time I was coding this. I might have done as well
> with object, but from memory there were some platforms where this didn't
> work as well. I assume it probably does now across all the browsers I care
> about, and I should probably look at updating.

In firefox, at least, the difference will be very minimal - they share the majority of their implementation.

(In reply to jonesr from comment #57)
> Hopefully whatever has changed here in FF 21 is
> something that can be fixed without having to get Oracle to fix anything at
> their end (even if the core problem is there), given FF 20 seems to have had
> something that at least worked for this case on the impacted platform
> (apparently recent Mac OS X versions).

This definitely seems to be a java bug, but I agree we should try to work around it if possible. Note, though, that unless the fix turns out to be very simple, it's not likely to make it into FF22.

(In reply to Georg Fritzsche [:gfritzsche] from comment #58)
> Right, but from what i see, when doing:
> > var p = document.getElementById('applet');
> ... we immediately request the scriptable object, even if the actual
> scripting happens much later. I wonder if we couldn't retrieve it when actual
> scripting occurs on a proxy object to reduce such problems - which might
> help if we were to make plugin instantiation async.

I'm not sure why this is touching the prototype, but any call that attempts to get a wrapper for the object is going to trigger this I believe. Fixing this would still leave more obscure edge cases that we should probably try to avoid.

    
    

    
  
(In reply to John Schoenick [:johns] from comment #40)
> So if Java expects an initial SetWindow message before being scripted, but
> also sometimes crashes if it gets SetWindow while inside a NPN call (bug
> 831768), 

Ah yes: -
https://bugzilla.mozilla.org/show_bug.cgi?id=831768#c11
Sage advice indeed from bajaj ! If only that voice of reason and caution had have been heeded above the Yee-Hawing of Smith & Wesson.

Yes OOP is the highest priority come hell or high-water (or stability it seems).

> there is no way I can see to 100% work around both quirks. We can
> try checking if we're inside a NPN call when a plugin is scripted, and flush
> pending SetWindows first if not, but it would still be possible to do
> re-entrant things like calling java code that calls javascript that spawns a
> new plugin and tries to script it -- unless the JRE fixes one bug or the
> other, I'm not sure we can fix that.

Perhaps, you certainly know better than me, but with Chrome, IE, Opera and FireFox on Windows AND Safari on OS/X all working beautifully it would seem that the obstacles are either surmountable or ill-perceived? More smoke, mirrors, and timing-windows?

> 
> On a side note, the current HTML5 spec does not provide any guarantees for
> spawning plugins synchronously (e.g. adding it to the DOM and immediately
> scripting it), and all browsers handle this slightly differently.

Good! No one’s asking for it to be synchronous. What we are demanding is that the HTMLObjectElement that you return from GetElementById(“MyApplet”) will eventually point to the activated Applet that will be scriptable AND you honour whatever it is that Oracle does to activate <param name="java_status_events" value="true"> which you appear to have also broken :-(

> Additionally, things like click-to-play might make the plugin spawn much
> later (after a user okays it). Ideally, then, the best way to talk with a
> plugin would be to add it to the document and have it send a callback to JS
> when it's ready and loaded.
 
Like Java Status Events perhaps?
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/applet/appletStatus.html

Anyway, I’m now stuffed with my applet activation on FireFox for OS/X (Having said that let me re-state that FF21 + Java7-21 + OS/X 10.7.5 works). 

So there must be chortling all over Apple, Google, Windows, and Mozilla worlds tonight? Well done :-(

Regards Hurt from Perth

    
    

    
  
(In reply to John Schoenick [:johns] from comment #59)
> This definitely
> seems to be a java bug, 

Excuse me??? This same version of Java and OS/X works with Safari. FF Worked on OS/X till FF21. It has worked and continues to work on Windows FF since V3.0. It works with Chrome, IE, And Opera on Windows and you have the audacity nay hubris to say "definitely".

> but I agree we should try to work around it if
> possible. Note, though, that unless the fix turns out to be very simple,
> it's not likely to make it into FF22.

Hoorah!

(In reply to Georg Fritzsche
> [:gfritzsche] from comment #58)
> Right, but from what i see, when doing:
>
> > var p = document.getElementById('applet');
> ... we immediately request
> the scriptable object, even if the actual
> scripting happens much later. I
> wonder if we couldn't retrieve it when actual
> scripting occurs on a proxy
> object to reduce such problems - which might
> help if we were to make
> plugin instantiation async.

I'm not sure why this is touching the
> prototype, but any call that attempts to get a wrapper for the object is
> going to trigger this I believe. Fixing this would still leave more obscure
> edge cases that we should probably try to avoid.

Or you could simply backout that bollocks change that should have failed any serious QA and regression testing. You broke the code! This is the Oh ****! moment that triggers the backout plan!

Cheers Richard Maher

    
    

    
  
Did a little debugging today and, at least in the test-case i'm looking at, Java does return a scriptable object, but appears to be in a broken state (where it says that it doesn't have such a method).
So it's definitely not something we could recover from once it's broken. Will try Johns suggestion next week and gather some details for Oracle.

(In reply to Richard Maher from comment #60)
> Good! No one’s asking for it to be synchronous. What we are demanding is
> that the HTMLObjectElement that you return from GetElementById(“MyApplet”)
> will eventually point to the activated Applet that will be scriptable AND
> you honour whatever it is that Oracle does to activate <param
> name="java_status_events" value="true"> which you appear to have also broken

The really reliable way, cross-browser, is - as John already noted - to have the plugin call into the page to signal that it's ready to do actual work.
That applet status and the event handlers depend on the plugin providing a working scriptable object when you access it, and Java simply doesn't cooperate in this case.

We may be able to work around that to match the behavior Java expects, but that doesn't make it less of a Java issue.

There won't be backout due to security and stability implications of bug 823559, which indirectly depends on bug 831768.

    
    

    
  
Thanks for the progress updates Georg. In terms of the java_status_events mentioned by the other Richard, I think this is somewhat of a red herring anyway. Its lack of working probably isn't reflecting any extra brokenness, it is just a symptom of the issue that nothing on the applet is visible from javascript when this bad initialised state arises - the non visibility of the status flag and the methods are probably all part of the same boat. 

Having the plugin provide event notifications when it is ready for work would be nice, but polling for when the methods become defined should be a viable alternative if it wasn't for the bug leading to the scriptable object never having these methods showing up. 

I appreciate you having a look at the issue, obviously a fix (or workaround for the java issue if that is where the fault lies) would be ideal, but it sounds like you'd be in a good position to file a bug with oracle too if it turns out there are strong reasons why a workaround isn't possible (or sensible given the other issues that interact with plugin initialisation). 

Regards,
Richard.

    
    

    
  
(In reply to Georg Fritzsche [:gfritzsche] from comment #62)
> Did a little debugging today and, 

Excellent, thank-you!

> at least in the test-case i'm looking at,
> Java does return a scriptable object, but appears to be in a broken state
> (where it says that it doesn't have such a method).

Big deal.

> So it's definitely not something we could recover from once it's broken.

Really? IE says it's broken but continues to build it lazily until we poll it for maturity. And then, guess what? The Java status events (or the "status" attribute itself) tells us that it is complete. It's amazing what you can do when you follow convention as you have done up until the self-confessed plugin hating vandals from Mozilla were let loose on the code :-(

How about don't break it in the first place? Or to steal a motto from a more responsible group "Above all else DO NO HARM!".

> Will try Johns suggestion next week and gather some details for Oracle.

Good luck with that. Unless your talking pinapple bug plagues in Hawaii or the America's Cup death toll, I don't think Larry's too interested these days :-(
> 
> (In reply to Richard Maher from comment #60)
> > Good! No one’s asking for it to be synchronous. What we are demanding is
> > that the HTMLObjectElement that you return from GetElementById(“MyApplet”)
> > will eventually point to the activated Applet that will be scriptable AND
> > you honour whatever it is that Oracle does to activate <param
> > name="java_status_events" value="true"> which you appear to have also broken
> 
> The really reliable way, cross-browser, is - as John already noted - to have
> the plugin call into the page to signal that it's ready to do actual work.
> That applet status and the event handlers depend on the plugin providing a
> working scriptable object when you access it, and Java simply doesn't
> cooperate in this case.

For Pete's sake; it's like the sign outside Grampa Simpson's ward that says "Please don't discuss the outside world". Mozilla FireFox is looking more and more like a bad remake of Lord Of The Flies and Ben's got the Conch :-(

My code WORKS cross browser extremely well thank you very much except some numpty in his quest to emulate Microsoft's Loosely Couple Internet Explorere (LCIE) has taken a sledge hammer to all that is good in this world. You want "cross-browser"? Then tell me why your **** "fix" has left the Mozilla group looking like a complete bunch of numpties when Safari, Chrome, Opera, and IE don't have a problem???
> 
> We may be able to work around that to match the behavior Java expects, but
> that doesn't make it less of a Java issue.
> 
> There won't be backout due to security and stability implications of bug
> 823559, which indirectly depends on bug 831768.

Don't want to upset the bully do we? 

Look I'm not questioning anyone's personal integrity or commitment to the project but if I was Google I'd be rubbing my hands at the resource selection for making these changes that impact the Java plugin. I'm sure Steve Jobs is dancing in his grave :-(

Disbelief!

Richard Maher

    
    

    
  
(In reply to John Schoenick [:johns] from comment #59)

> Note, though, that unless the fix turns out to be
> very simple, it's not likely to make it into FF22.

https://bugzilla.mozilla.org/show_bug.cgi?id=872969#c31 seems to be as simple as you can get. Ship with that config - Job done!

Once OOPP is no longer flipped over on the beach with its wee flippers flailing madly in the air you can turn it back on.

    
    

    
  
(In reply to Georg Fritzsche [:gfritzsche] from comment #62)
> 
> The really reliable way, cross-browser, is - as John already noted - to have
> the plugin call into the page to signal that it's ready to do actual work.

But Georg, how do you and John propose to inform the JavaScript of a failure to load? ESP? Vulcan Mind Meld? Osmosis?

Admittedly the last line of defence in my load checker is a maximum number of polls, but the java status events are there to enable a timely response to changes in load state and reduce the reliance on heuristics?
> 
> We may be able to work around that to match the behavior Java expects, but
> that doesn't make it less of a Java issue.

How are you getting on?
> 
Cheers Richard Maher

PS. You're probably not a Bayern fan but well done to them anyway! (The year and a bit my wife & I spent in Munich was some of the best times of our lives) Does Alliance have a Sud Curve?

    
    

    
  
(In reply to Richard Maher from comment #66)
> (In reply to Georg Fritzsche [:gfritzsche] from comment #62)
> > The really reliable way, cross-browser, is - as John already noted - to have
> > the plugin call into the page to signal that it's ready to do actual work.
> 
> But Georg, how do you and John propose to inform the JavaScript of a failure
> to load?

If you mean Java failing to load - that's a general problem with plugins and not specific to this issue. Overall there isn't really a better option AFAIK than to assume a failure to load, click-to-play block, ... based on an empirically chosen time-out.

I will check into this issue later this week and will update when i know more.

    
    

    
  
(In reply to Georg Fritzsche [:gfritzsche] from comment #67)
> 
> If you mean Java failing to load 

No, I was thinking more of the user who says NO to click-to-play, or the class name not found etc. This is where java-status-events are able to inform the JavaScript of the failure. IOW The plugin loaded tickety-boo but the individual Applet(s) has issues.

> - that's a general problem with plugins and
> not specific to this issue. 

Yes, this failure scenario also has to be catered for.

> Overall there isn't really a better option AFAIK
> than to assume a failure to load, click-to-play block, ... based on an
> empirically chosen time-out.

The polling + max-polls for me is a better option because things like click-to-play suspend the timer event processing so false positives are mminimized.

For most success/fail scenarios with loading applets, the code I have attached and its utilization of the timely Java Status Events seems to be the elephant in the room here. Unless this is what you and John were referring to? I thought/assumed you were asking every Applet's init method to call into Java to say "OK to go"? If you were in fact referring to the "plugin" then put down that chisel Korg as the wheel is already here and invented by Oracle.

> 
> I will check into this issue later this week and will update when i know
> more.

Excellent! Thank-you.

As FireFox 22 will have the Java plugin in-process by default, you can take all the time you want.

Cheers Richard Maher

    
    

    
  
Georg I understand if you have to pack your bags and head for high-ground and we don't hear from you for a while. Good-Luck!

BTW. 64-bit Opera on OS/X works just fine too.

Cheers Richard Maher

    
    

    
  
(In reply to Doug South from comment 882030#1)
> Liveconnect *is* working in FF 22.0b4. I just want to make sure that this
> doesn't slip into the 22.0 release.

Hi Doug,

Just checking if that LiveConnect test was with the Java plugin OOP or in process?

Cheers Richard Mhher

    
    

    
  
Hi Richard,

I'm not sure which it would be. What is OOP? What is in process? And how do they differ?

Regards,
Doug

    
    

    
  
I don't have

dom.ipc.plugins.java.enabled

in either FF 21 or FF 22.0b5. I do have 

dom.ipc.plugins.enabled.i386.javaappletplugin.plugin 

and 

dom.ipc.plugins.enabled.i386.javaplugin2_npapi.plugin

No combination of either of those solves my issue.

We are dynamically creating the object tag for the applet, so it *sounds* like this is the same issues as what I'm seeing, but I haven't confirmed that yet.

    
    

    
  
Hi Doug,

Thanks for clarifying.

Try adding dom.ipc.plugins.java.enabled in 21 and set it to false and see if that "fixes" your problem.

From what you say the good news is that the problem is fixed/gone-away in 22?

Either it's fixed or they decided to turn off OOP by default in 22? Either way I'm over the moon!

I pretty sure Georg must have cleared away all the sand-bags by now so I'm eagerly awaiting his update.

Cheers Richard Maher

    
    

    
  
Sorry, took a little longer to get to this than i expected.
Some of the obvious options i tried were not helpful at all (e.g. back to crashes). One option i checked out now though seems to at least not break the test-case i looked at.

Please take [1] for a test ride with your affected use-cases and let me know if that build works.

[1] http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/georg.fritzsche@googlemail.com-35ba4d597d94/try-macosx64-debug/firefox-24.0a1.en-US.mac64.dmg

    
    

    
  
Thanks Georg, 

That worked fine for my use case, although it sounds from others that FF 22 beta might also work, but I haven't tried any of the 22 betas yet to confirm that, but it might indicate there have been other changes made to FF 22 that might have helped this? In any case, the nightly worked fine for me, thanks for the work you've put in looking at this.

Regards,
Richard.

    
    

    
  
(In reply to jonesr from comment #76)
> That worked fine for my use case, although it sounds from others that FF 22
> beta might also work, but I haven't tried any of the 22 betas yet to confirm
> that, but it might indicate there have been other changes made to FF 22 that
> might have helped this?

Right, although i'm a bit wary of this as i hit it in recent Fx 24 builds. This is definitely timing sensitive (i did never hit it 100%), so maybe thats why it isn't seen in all versions.

Could you possibly check if you see this in a current Firefox Nightly [1]?

[1] http://nightly.mozilla.org/

    
    

    
  
Doug, could you test your testcase with Nightly from https://bugzilla.mozilla.org/show_bug.cgi?id=872969#c75 please.
Flags: needinfo?(doug.south)

    
    

    
  
Hi Georg,

Those official nightly builds are also currently working for me. Note that I agree the issue is timing related, as I had it actually work 1 time for me with FF 21, but that was 1 time out of probably 30-40 attempts. It is possible that some other changes have nudged the timing in favour of not showing the bug, and your changes are actually a proper fix, but I can't say from what I see now, as I can't reproduce in both your nightly or the official nightly (which I assume doesn't have your change). I've tried a few times, and don't see any examples of the old bug that was showing on FF21.

Regards,
Richard.

    
    

    
  
Thanks for checking Richard.

So, i'm curious if anyone can reproduce this issue at all in Fx 22+?

24 can be found here here: http://nightly.mozilla.org/
... and 23 here: http://www.mozilla.org/en-US/firefox/channel/#aurora

    
    

    
  
Sorry Georg,

Upon further testing, I do get failure cases with your nightly build, it just happens much less often than on FF21. I'm having a bit of trouble testing with the official nightly builds to see if that also triggers the bug sometimes, as the official nightly is crashing on load on most attempts, in fact I can't get it to load at all right now, and it has only loaded once for me (and didn't show the bug at that time), but I would guess if I tried a few more times it will probably trigger the bug eventually too.

Regards,
Richard.

    
    

    
  
First off, I thought our issue was fixed with FF22 beta, but that's before I fully understood what was wrong and then re-tested and found that it did *not* fix the issue.

I've quickly spun up the nightly build and did some quick testing with it and thus far it looks good. I see that there may be some timing failures, so I'll poke it a bit harder later today if I get the chance.
Flags: needinfo?(doug.south)

    
    

    
  
(In reply to Georg Fritzsche [:gfritzsche] from comment #80)
> Thanks for checking Richard.
> 
> So, i'm curious if anyone can reproduce this issue at all in Fx 22+?
> 
> 24 can be found here here: http://nightly.mozilla.org/
> ... and 23 here: http://www.mozilla.org/en-US/firefox/channel/#aurora

On a quick inspection of both 24 and 23 I haven't seen this bug. Quick being just one load and a couple of reloads...

    
    

    
  
I've loaded up our page 20 times with the debug build, 20 times with FF 23 and 15 times with FF 24:

Nightly debug was good every time.
FF 23 hung once, but was good all the other times
FF 24 hung 2 times, but was good all other times

    
    

    
  
Hi Georg,

Any progress on this? See the End-Of-Financial-Year out with a bang?

Cheers Richard Maher

    
    

    
  
So, if i understand the situation right from the last comments:
* this is still present in later releases, just sometimes harder to trigger due to timing differences
* my patched build above also doesn't fix it, which was the last feasible work-around i had

So, unless i'm interpreting the above comments wrongly, this is an issue we won't pursue further. Please file a bug for the Java plugin [1] and i'll forward them details if needed.

[1]: http://bugs.sun.com/ probably, or whatever channel Oracle customers have

    
    

    
  
I didn't see any issues in the versions I tested and reported on...

    
    

    
  
(In reply to Doug South from comment #87)
> I didn't see any issues in the versions I tested and reported on...

Per comment 81 et al though the issue seems to exist in later versions and not be fixed by the work-around.
You don't seem to trigger it at all in FF23+ (ignoring unrelated hangs), with my best guess on why being timing differences.

    
    

    
  
Doug, Can you please provide a failure example or at least explain the exact issue because unlike you I don't "fully understand the problem". F22 works for me (the minimal testing/retries that I've done). Are you saying that I should expect it to fail again in 23,24 etc? Cheers Richard

    
    

    
  
(In reply to Richard Maher from comment #89)
> Doug, Can you please provide a failure example or at least explain the exact
> issue because unlike you I don't "fully understand the problem". F22 works
> for me (the minimal testing/retries that I've done). Are you saying that I
> should expect it to fail again in 23,24 etc? Cheers Richard

Hi Richard,

FF 22 appears no different to me to FF 21. With your "chan.status" check version of the live connect initialisation test running here:
http://chesstempo.com/test/bad-liveconnect3.html

I get the same behaviour as in FF 21, i.e. status never becomes defined on the applet.

I suspect that setting dom.ipc.plugins.java.enabled to false , will again be the only thing that works for me. Georg's nightly build I tested with a while back seemed to improve things, but I got one failure case there too, so it seems Georg's fix might just make it harder to reproduce, but for me FF 22 has the same close to 100% repeatable rate that FF 21 had, although I've only tried 6 or 7 times so far, but haven't seen it work once yet. My understanding is that Georgs build has changes not included in FF22?
 
Regards,
Richard.

    
    

    
  
I ran into this bug and made a page to test and document it (before I found this bug report):
http://concord-consortium.github.io/applet-tests/timing/

I don't have my 10.7 machine with me, so I can't verify if that page still shows failures with the work-around build. Or that it starts passing with dom.ipc.plugins.java.enabled=false.  I did test the page with both FF 21 and FF 22 and it showed failures on both. And I also did a bisect and found that  2013-03-26 worked but 2013-03-27 failed. These are different versions than were reported above:
2013-03-19 worked, 2013-03-20 failed. That might indicate something new or it might just be that commits were being added and removed between  3-19 and 3-27. 

One tidbit is that you can detect if the applet dom element is accessed too soon by looking at the toString of the element. If the applet wasn't ready yet then the value will be: [object HTMLAppletElement]. But as is documented here, once you call toString you are stuck and the only fix is reloading the page.

Also looking at the 'simple test case' from will@onsip.com sometimes it is not enough to just wrap the applet access in a setTimeout{...,0}, on my test page I needed to wait for 50ms. But I think that varies depending on the other page content.

If the applet's init method has been called does that guarantee that SetWindow has been called? Has anyone verified that notifying JS in the applet's init call means it is safe afterwards for JS to reference the applets dom element?

    
    

    
  
(In reply to Scott Cytacki from comment #91)
> I ran into this bug and made a page to test and document it (before I found
> this bug report):
> http://concord-consortium.github.io/applet-tests/timing/
> 
> I don't have my 10.7 machine with me, so I can't verify if that page still
> shows failures with the work-around build. Or that it starts passing with
> dom.ipc.plugins.java.enabled=false.  I did test the page with both FF 21 and
> FF 22 and it showed failures on both. And I also did a bisect and found that
> 2013-03-26 worked but 2013-03-27 failed. These are different versions than
> were reported above:
> 2013-03-19 worked, 2013-03-20 failed. That might indicate something new or
> it might just be that commits were being added and removed between  3-19 and
> 3-27. 
> 
> One tidbit is that you can detect if the applet dom element is accessed too
> soon by looking at the toString of the element. If the applet wasn't ready
> yet then the value will be: [object HTMLAppletElement]. But as is documented
> here, once you call toString you are stuck and the only fix is reloading the
> page.
> 
> Also looking at the 'simple test case' from will@onsip.com sometimes it is
> not enough to just wrap the applet access in a setTimeout{...,0}, on my test
> page I needed to wait for 50ms. But I think that varies depending on the
> other page content.
> 

Trying your test, I can never get the applet method call to work (i.e. always "fail" in your test log). I tried timeouts of 0, 1, 5, 50 and 5000, and all produced "fail" results. This is on the official FF 22 release on a Mac book pro with 4 CPU cores, running Mac OS X 10.8.3.

> If the applet's init method has been called does that guarantee that
> SetWindow has been called? Has anyone verified that notifying JS in the
> applet's init call means it is safe afterwards for JS to reference the
> applets dom element?

I haven't recently tried notifying to the javascript side from the applet from within init, although I did try that approach in the past, unfortunately I don't recall why I abandoned it (most of this work was done 3 years ago). However JSObject.getWindow(this) run inside init() always returns what looks like a Window reference for me in these fail cases, so it looks like the window is set from the Java side's point of view by the time init is finished being called, and indeed, probably set before init is called (unless my test code calling getWindow explicitly sets it at that point, which is possible).

Regards,
Richard.

    
    

    
  
Gentlemen,

I didn't re-check the config after downloading 22 and sure enough dom.ipc.plugins.java.enabled was still set to false. My apologies for the red-herring and school-boy mistake.

When it comes to this idea of using the init() method to call into JS to fudge around Ben's bug in OOP let me once again point out that we are not in an FF vacuum. If Ben was trying to copy Chrome then he missed the mark by a long shot as Chromes processes don't miss a beat with Java. (If he was trying to emulate Internet Explorers LCIE then he may well be closer to the mark.)

Either way Safari and Opera64 are fine on OS/X and everything is just peachy on Windows!

This bug was introduced/latency-discovered by Ben when he was "fixing" other bugs that was supposed to be for the benefit of Java. See: - https://bugzilla.mozilla.org/show_bug.cgi?id=872969#c60

If Georg is out of his depth (pun about the floods :-) then can John S have a go?

Please don't let your hatred of Java blind you to an obvious FF bug.

Cheers Richard Maher

    
    

    
  
(In reply to Scott Cytacki from comment #91)
> I don't have my 10.7 machine with me, so I can't verify if that page still
> shows failures with the work-around build. Or that it starts passing with
> dom.ipc.plugins.java.enabled=false.

I tested dom.ipc.plugins.java.enabled=false on 10.7 with my test page and that seems to cause the browser to crash or the plugin to crash. On 10.8 nothing crashes, and the test passes even when no setTimeout is used before accessing the applet.

(replying to Richard Maher from comment #92)
> Trying your test, I can never get the applet method call to work (i.e. always
> "fail" in your test log). I tried timeouts of 0, 1, 5, 50 and 5000, and all
> produced "fail" results. This is on the official FF 22 release on a Mac book
> pro with 4 CPU cores, running Mac OS X 10.8.3.

I borrowed a quad core 10.8.3 machine with the official FF 22 release and the test passes for me with an initalDelay of 1. Perhaps there is variation based on network delays or java settings.

    
    

    
  
(In reply to Georg Fritzsche [:gfritzsche] from comment #75)
> Some of the obvious options i tried were not helpful at all (e.g. back to
> crashes). 

Georg can you elaborate on what you tried?

> One option i checked out now though seems to at least not break
> the test-case i looked at.
> 
> Please take [1] for a test ride with your affected use-cases and let me know
> if that build works.
> 
> [1]
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/georg.
> fritzsche@googlemail.com-35ba4d597d94/try-macosx64-debug/firefox-24.0a1.en-
> US.mac64.dmg

This isn't available anymore. I'm more interested in the changeset then the build, can anyone point me at that?

As Georg said it seems this should be fixed in the plugin. Otherwise Mozilla would need to special case how it interacts with the Java plugin. Based on comment #62 and comment #40, the plugin should handle the case where the scriptable object is requested before SetWindow is called. Do I have that right?

If there is no movement from Oracle on this, would Mozilla consider adding the following work around: if SetWindow hasn't been called yet then don't ask the plugin for a scriptable object and instead throw an exception. This would at least let the javascript code know that something was not initialized yet, and it could retry later. It seems better to fail fast with an exception instead of returning a partially broken object. However, this would break current javascript code that only accesses 'browser properties' of the applet like width, height, or style. In my opinion that regression would be worthwhile since it would make the issue more clear.

    
    

    
  
(In reply to Scott Cytacki from comment #94)
> I borrowed a quad core 10.8.3 machine with the official FF 22 release and
> the test passes for me with an initalDelay of 1. Perhaps there is variation
> based on network delays or java settings.

What was the value of dom.ipc.plugins.java.enabled when you ran that test?

    
    

    
  
(In reply to jonesr from comment #96)
> (In reply to Scott Cytacki from comment #94)
> > I borrowed a quad core 10.8.3 machine with the official FF 22 release and
> > the test passes for me with an initalDelay of 1. Perhaps there is variation
> > based on network delays or java settings.
> 
> What was the value of dom.ipc.plugins.java.enabled when you ran that test?

I 'reset' it, so I assume it would revert to true. I restarted FF after change it to make sure the plugin was reloaded. To be clear I was running this test:
http://concord-consortium.github.io/applet-tests/timing/
to see if I could reproduce the constant fails that Richard reported in comment #92

    
    

    
  
(In reply to Scott Cytacki from comment #97)
> (In reply to jonesr from comment #96)
> > (In reply to Scott Cytacki from comment #94)
> > > I borrowed a quad core 10.8.3 machine with the official FF 22 release and
> > > the test passes for me with an initalDelay of 1. Perhaps there is variation
> > > based on network delays or java settings.
> > 
> > What was the value of dom.ipc.plugins.java.enabled when you ran that test?
> 
> I 'reset' it, so I assume it would revert to true. I restarted FF after
> change it to make sure the plugin was reloaded. 

Yes, that seems like a safe assumption, although I've explicitly set it to true for my tests, I assume that should be no different to resetting it.

> To be clear I was running
> this test:
> http://concord-consortium.github.io/applet-tests/timing/
> to see if I could reproduce the constant fails that Richard reported in
> comment #92

comment #92 is actually me, not "Richard Maher" (problem in the quoting?).

I continue to see nothing but fails with FF22 and that test with initialDelay set to 1. The only java plugin setting that I can think of that might be relevant here is that I have the java console turned on which I guess could significantly change the timing , and therefore impact reproducibility.

Regards,
Richard.

    
    

    
  
(In reply to Scott Cytacki from comment #95)
> (In reply to Georg Fritzsche [:gfritzsche] from comment #75)
> > Some of the obvious options i tried were not helpful at all (e.g. back to
> > crashes). 
> 
> Georg can you elaborate on what you tried?

Specifically variations of calling SetWindow() before requesting a scriptable object.

> This isn't available anymore. I'm more interested in the changeset then the
> build, can anyone point me at that?

The changesets for the revision are still available:
https://tbpl.mozilla.org/?tree=Try&rev=35ba4d597d94

> if SetWindow hasn't been called yet then don't
> ask the plugin for a scriptable object

This is what the above changeset does, which apparently didn't work for everyone - so maybe SetWindow() is a red herring here and it really depends on some other condition.

    
    

    
  
Can somebody please explain Mozilla recalcetrance in not turning off OOPP in FF by default on non-Windows browsers? Especially in light of this obvious breaking bug! An absolute bloody mystery :-(

When it comes to fixing the bug one need look no further than https://bugzilla.mozilla.org/show_bug.cgi?id=831768 Simply find the code before Ben set his 6-shooters on it and you will see alles peachy. Then looking at the changes that were made in the "fix" should illuminate what went wrong. Sound like a plan?

Sadly someone, not a million miles from this thread, was heard to say "This looks good to me" :-(

I suspect something serious in hidden Bug 823559 led to the bulldozing of Ben's work without proper scrutiny.

Cheers Richard Maher

    
    

    
  
Have you actually tried running the test-case with Java OOP on a build with bug 831768 backed out?

    
    

    
  
(In reply to Georg Fritzsche [:gfritzsche] from comment #101)
> Have you actually tried running the test-case with Java OOP on a build with
> bug 831768 backed out?

Naturlich!

No of course not :-)

1) I don't have the technical ability
2) I don't have the time
3) It's much easier to sit on the sidelines and poke fun than do the work.

Having said that what I have run successfully is FF20. Didn't miss a beat!

So if you don't like C100 then a coarser grained approach would be to start will FF20 and see what was introduced to break the code?

Cheers Richard Maher

    
    

    
  
(In reply to Richard Maher from comment #102)
> Having said that what I have run successfully is FF20.

Well, sure - Firefox 21 is where Java was moved out-of-process again for non-Windows platforms and that means slightly different behavior, timings, ...  especially regarding the weirder Java issues.

To recap:
* Java seems to have a bug where it sometimes returns an unusable scriptable object
* we could probably work around it if we had an easy fix
* i haven't found an easy fix with the information at hand
* as it doesn't seem to be our problem, putting extensive time into this isn't really feasible

Closing for now for the above, but i'm happy to look into reasonable suggestions for workarounds.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX

    
    

    
  


  
Only Gott knows what sort of acceptance testing was carried out on Ben's work (if any) but the "solution" is ostensibly ill-designed and unfit for purpose :-(

With the only visible success criteria being "Can we run Flash in a separate process - Yahoo!" I just wish an adult could wade on to this Lord of the Flies islands and bash a few heads together. Or at least someone old enough to shave and remember what "Software Engineering" meant.

    
    

    
  
(In reply to Georg Fritzsche [:gfritzsche] from comment #103)
> (In reply to Richard Maher from comment #102)
> > Having said that what I have run successfully is FF20.
> 
> Well, sure - Firefox 21 is where Java was moved out-of-process again for
> non-Windows platforms and that means slightly different behavior, timings,
> ...  especially regarding the weirder Java issues.
> 
> To recap:
> * Java seems to have a bug where it sometimes returns an unusable scriptable
> object
No it is architected behaviour by design. You are have failed to either: -
. mutex/lock the correct resource before requesting the object
. an event needs to be specified to obtain a complete object
. convention requires you to poll on the object
. the OS/X release notes from 10.7.5 to 10.8.3 contain the missing information about new non-blocking behaviour 
. all of the above 
> * we could probably work around it if we had an easy fix
Ship with config:- dom.ipc.plugins.java.enabled=false 
> * i haven't found an easy fix with the information at hand
See above.
> * as it doesn't seem to be our problem, putting extensive time into this
> isn't really feasible
You are mistaken.
> 
> Closing for now for the above, but i'm happy to look into reasonable
> suggestions for workarounds.

Georg can you please explain what is unreasonable about turning off OOP for Java by default? No user asked for it; no user wants it. 

If you continue to refuse to budge then can you please provide a pointer to the source for getScriptingObjectForApplet? I don't seem to have it in my FireFox source files.

Cheers Richard Maher

PS. Please don't take this personally, but if you've gone as far as you can with this bug and have nothing further to add, can you please remove your name so that someone else like John Shoensten can have a go? He seems to know a fair bit in this area!

PPS. If [Marco||Mario|Michelle] Fabbri could "re-open" this bug I would be very happy!

    
    

    
  
(In reply to Richard Maher from comment #105)
> No it is architected behaviour by design. You are have failed to either:

No, as soon as plugin instance was initialized by the browser it should either return a valid scriptable object or none. Everything else is plugins incorrectly depending on unspecified behavior.

> Georg can you please explain what is unreasonable about turning off OOP for
> Java by default? No user asked for it; no user wants it. 

All plugins run out-of-process for, among other things, stability reasons - otherwise they would always take down the browser when crashing.
Java only got an exception due to the linked bugs in bug 823559, comment 1. 

> can you please provide a pointer to
> the source for getScriptingObjectForApplet?

The changeset from comment 99 points to the interesting functions in the child process. Looks like it was lost in the try reset, attaching that patch in a sec.

    
    

    
  


  
The mentioned patch, in particular note PluginInstanceChild::AnswerNPP_GetValue_NPPVpluginScriptableNPObject().

    
    

    
  
Hi Georg,

Don't get me wrong I will log a bug with Oracle over this once all alternatives are exhausted but, not to put too fine a point on it, they're usually not as helpful or engaging as Mozilla people. So please bear with me.

I know your code is littered with assertPluginThread() but this really stood out for me at: - https://developer.mozilla.org/en-US/docs/Gecko_Plugin_API_Reference/Scripting_plugins

"NPPVpluginScriptableNPObject = 15
 
Threading model
 
This API is not designed to be thread safe. The threading model for this API is such that all calls through this API are synchronous and calls from a plugin to methods in this API must come from the thread on which the plugin was initiated, and likewise all calls to methods in this API by the browser are guaranteed to come from the same thread. Future revisions to this API might provide a mechanism for proxying calls from one thread to another to aid in using this API from other threads.
"

Would earlier FF calls not in the Plugin Thread lead to the race condition we are witnessing having manifested itself in the OS upgrade from 10.7.5 to 10.8.3?

Can anyone else establish that FF21+ works peachy on OS/X 10.7.5 or lower?

Cheers Richard Maher

    
    

    
  
(In reply to Richard Maher from comment #108)
> Would earlier FF calls not in the Plugin Thread lead to the race condition
> we are witnessing having manifested itself in the OS upgrade from 10.7.5 to
> 10.8.3?

From the comments i can't really see anything that goes beyond timing issues, which may differ between OS releases, machines, setups, etc.

The relevant Firefox calls for initialization (NPP_New, SetWindow, retrieving the scriptable object) are definitely on the main thread: they come in via our IPC mechanism and are processed on the main thread.
What can (and does) happen is that Java calls some things incorrectly off-main-thread, but this shouldn't matter for the problem at hand.

    
    

    
  
I've been keeping an eye on this issue, as it has a severe impact in a product I work on. We logged it with Oracle late last week, SR 3-7583925241. There is no bug reference yet as we are still in the process of convincing them it is a bug, but we have had some success with asking them to fix OS X applet bugs in the past.

I have just loaded up our 10.7.5 test machine and FireFox 22 does not work.

    
    

    
  
We escalated it this morning (we're in Australia). We now have a bug reference - 17232568.

    
    

    
  
Well done Andrew!

    
    

    
  
Having said that I get "This bug is unavailable": -
http://bugs.sun.com/view_bug.do?bug_id=17232568

Is it not publicly visible or am I miss-typing?

    
    

    
  
It was logged via a business support contract, so it's probably still internal. I don't know what the conditions are for making them public (although they always appear on the change list when released).

    
    

    
  
Hi Andrew,

It's been a while; any feed-back from Oracle on this issue? Have they acknowledged a bug on the Java side?

Cheers Richard Maher

PS. Sorry to piggy-back on this bug but I had a similar Applet bug lodged with Oracle. That I also cannot see from the bugs.com interface: -

http://bugs.sun.com/view_bug.do?bug_id=9005723

In a nutshell, the plugin's JSObject.call() method cannot pass arrays to JavaScript. As Java method parameters and return-values, JavaScript arrays are fine including a uint8array() backed-up by an ArrayBuffer.

Can anyone see the code in iced-tea exhibiting the same behavior with CALL()?

    
    

    
  
I have been given a JRE build that fixes the problem, we're trying to convince Oracle to squeeze the fix into 7u40 :)

    
    

    
  
(In reply to Andrew Herron from comment #117)
> I have been given a JRE build that fixes the problem, we're trying to
> convince Oracle to squeeze the fix into 7u40 :)

You bewdy!

My apologies to the Mozilla people and Ben in particular for ever having casted aspersions on their skills, competence, and thoroughness. Ben bears no resemblance to Yosemite Sam.

I knew it was a Java bug all along :-)

Cheers Richard Maher

    
    

    
  
Hi Andrew,

I see 1.7.0_40 is out. Did your bug-report fix make it in?

Cheers Richard

    
    

    
  
Unfortunately the fix wasn't complete in time to make 7u40, but we've been told an out-of-band 7u45 update is planned (ETA October) that does include it.

    
    

    
  
(In reply to Andrew Herron from comment #120)
> Unfortunately the fix wasn't complete in time to make 7u40, but we've been
> told an out-of-band 7u45 update is planned (ETA October) that does include
> it.

Doesn't look like 9005723 made it either :-( Fingers-crossed for 7u45.

Thanks for the update.

Cheers Richard Maher

    
    

    
  
While I understand this is an Oracle bug, I don't understand why "dom.ipc.plugins.java.enabled" is not set to false by default in Firefox for OSX like it is for Windows?

Could someone shed some light ?

Thanks,
Did

    
    

    
  
We default those prefs to true, we just haven't gotten to bug 874167 yet which will make Java OOP on Windows again.

    
    

    
  
I've been waiting for the Java bug to be fixed and released (hopefully Monday?) so I can test out OOP behavior with FF on OS/X (on Windows it just hangs or dies or crashes or all of the above :-)

But I'd be very grateful if someone could just confirm that FireFox with OOP enabled honours and preserves the existing in-process behavior of shared Static variables and the same classloader instance?

IOW, please, PLEASE, tell me your OOP behaves a la mode de Chrome and not like that disastrous IE model that requires the registry entry TabProcGrowth to be < 2 in order to preserve what has been supported and architected for years.

Ok, it was tweaked with the new plugin: -
http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html#cache

Cheers Richard Maher

BTW, can someone please tell me if there is any documentation to stipulate +/- explain why plugins don't work with desktop webapps? Or is it just Java again :-(

    
    

    
  
Do we know if this bug is present on windows when it is turned on? Because it's a very nasty bug, not easy to repro (unless you know it if FF>20+OSX+JSObject), takes long to identify and generate a lot of frustration for my users. The solution: asking them to manually alter their FF config if they're on a MAC is not awesome too (I tried setTimeout up to 1s delay without success, and I need java for real filesystem access).
So I hope we get a solution fast, and I'm still concerned that users upgrade their browsers quicker than java so developers can't rely on the fix and users will still be affected for a while.

(In reply to Georg Fritzsche [:gfritzsche] from comment #123)
> We default those prefs to true, we just haven't gotten to bug 874167 yet
> which will make Java OOP on Windows again.

    
    

    
  
(In reply to dcolens from comment #125)
> Do we know if this bug is present on windows when it is turned on?

Currently no. However, from previous comments Oracle has a fix coming up and our changes would still take 12-18 weeks to get into a release after they landed.

(In reply to Richard Maher from comment #124)
> But I'd be very grateful if someone could just confirm that FireFox with OOP
> enabled honours and preserves the existing in-process behavior of shared
> Static variables and the same classloader instance?

We only use one plugin process, so there shouldn't be any change regarding shared static variables etc.
Lets stay focused on this bugs subject though and move tangential discussions to suitable channels (like e.g. [1] for webapps).

[1] https://wiki.mozilla.org/Apps#IRC_Chat_and_Mailing_Lists

    
    

    
  
> We only use one plugin process, so there shouldn't be any change regarding shared static variables etc.

Thanks Georg. VERY glad to hear it.

> Lets stay focused on this bugs subject 

No worries and sorry for trying to take advantage and piggy-back any Mozilla issues I have on this bug. Your problem is you are far too helpful and responsive :-)

-------- Original Message --------
Subject: Desktop Plugin support with WebApps
Date: Sun, 29 Sep 2013 18:49:19 -0700 (PDT)
From: maherrj@googlemail.com
Newsgroups: mozilla.dev.webapps

Hi,

Are any Plugins supported for WebApps on the desktop? Java in particular?

I have an Applet on a page that functions perfectly in FF V24 but once it is installed "successfully" the plugin doesn't load and the Applet doesn't run.

Is there a Manifest option to enable plugins? Does Flash work?

Cheers Richard Maher

    
    

    
  
Ground Hog day: -

 Hi Andrew,

I see 1.7.0_40 (now 45) is out. Did your bug-report fix make it in?

Cheers Richard

    
    

    
  
Java 7 Update 45 resolves the issue listed in this defect for me. 

I hope that helps!
Michael

    
    

    
  
Yup. It screws up users of applets with new security warnings and requirements on the applet jar, we had to do an emergency release yesterday, but it does fix the FireFox LiveConnect issue.

    
    

    
  
Thanks Andrew and Michael. Yep one step forward an 5 back :-(

I can actually see the sense of Caller-Allowable-Codebase especially in this day of cross-domain script but how could they blind-side everyone in an unannounced feature to a maintenance release?

The killer for me is how can this not be an applet/object PARAM tag??? How does the author of the Applet/Manifest have the faintest idea of who should be calling in?

Sure I'm gonna put a wildcard like everyone else but I kinda agree with what they're trying to do but can't indulge the foolish placement of the functionality.

Anyway, thanks again to Mozilla and Georg in particular. I'm going to find somewhere else to moan :-)

Cheers Richard Maher

    
    

    
  
Thanks to all those who helped look into this. Now I just need to find out why I'm suddenly seeing the same behaviour in Safari on the mac with the latest java, but at least that is not the mozilla folk's problem :-)

    
    

    
  
Am still seeing the same behaviour with 1.7.45, unless I set dom.ipc.plugins.java.enabled to false.

    
    

    
  
(In reply to dcolens from comment #133)
> Am still seeing the same behaviour with 1.7.45, unless I set
> dom.ipc.plugins.java.enabled to false.

This bug is caused by a specific issue in java that is fixed in .45, so you're likely encountering a different issue. Could you open a new bug for this, preferably with a minimal test-case?

    
    

    
  
If a new bug is opened can someone please post the reference here?

I know there are people here using the <div>.innerHTML = "OBJECT. . .>" method of loading applets at run-time. If any of your applets still work please let me know? Mine fails silently (no pop-up for user approval) unless you have the Java Console on and logging set to 5. In which case you will see something like: -

liveconnect: Security Exception: JavaScript from http://127.0.0.1/employee_lookup.html attempted to access a resource it has no rights to.

My manifest has been amended with Caller-Allowable-Codebase: * (What a stupid place to put it?)

BTW This is all browsers and not just FF and once again I acknowledge that it is bad form to abuse this forum.

Cheers Richard Maher

    
    

    
  
Actually, I'm still seeing some intermittent failures on FF too, but haven't had time to investigate fully yet. It happens less often than previously. It is also failing on Safari now, with exactly the same symptoms as the old problem (applet object being returned, but members not being defined). Not really clear that 1.7.45 really does solve this issue.

    
    

    
  
Just keeps getting better :-( https://addons.mozilla.org/en-US/firefox/blocked/p463

So I don't know if it was the browser(s), or the Applet being unsigned, or the Applet being loaded dynamically at run-time, that caused the new there-be-dragons pop-up not to be displayed but hosting the web-page in the same domain as the Applet works-around the problem.

It appears Caller-Allowable-Codebase only works if the Applet is signed by a certificate authority, but does that help if the web-site was loaded with http instead of httpS in the first place? And shouldn't Caller-Allowable-Codebase really be called Caller-Allowable-DOCUMENTbase? Look if this check ensured that only script files included in the HTML were from the same domain as the Applet then this could be brilliant, but it only seems interested in the unverified parent location :-( 

To add insult to injury 9005723 did not make it in this release either. So you LiveConnect calls still can't pass Java arrays as arguments to JavaScript functions.

Cheers Richard Maher

    
    

    
  
jonesr@gmail.com: What you're seeing is more likely the applet security level. When set to very high, liveconnect is blocked with no way around it. If your JRE detects it is out of date, even high starts blocking liveconnect.

    
    

    
  
Andrew: I'm not sure if that is the case for me, as it seems toggling only dom.ipc.plugins.java.enabled changes the behaviour for me, with no other changes. I'll need to do some more testing, but I suspect I'm still seeing inconsistent state in the setting up of the applet in the same manner I have been before .45. Whether I'm still doing something wrong with my own initialisation or not remains to be seen, but given settings dom.ipc.plugins.java.enabled back to false appears to make it work reliably again , from my point of view there are still similar issues at play with .45. For me .45 just makes the failure under Safari more reliable, I'd seen the odd failure to load there too in the past (which was why I was happy to believe this was a Java issue rather than a Firefox issue, despite it previously being more reliably a problem on Firefox), but now it shows the behaviour very reliably (i.e. applet object appears to exist, but no members available). Given others seem to be happy with the problem going away under .45, it is possible I'm just doing something stupid. Will have some more time to test later in the week.

    
    

    
  
Sorry for the false alarm, things do indeed look ok for me on 0.45 now. It was a permission issue, for some reason my firefox thinks 0.45 is 0.6 and is putting a very hard to see little red icon next to the toolbar hiding the permission issue beneath a click on the red icon. Does anyone else have their Firefox on Mac OS X thinking their latest java is in fact an older version and therefore require user intervention to give permission?

    
    

    
  
(In reply to jonesr from comment #140)
> Sorry for the false alarm, things do indeed look ok for me on 0.45 now. It
> was a permission issue, for some reason my firefox thinks 0.45 is 0.6 and is
> putting a very hard to see little red icon next to the toolbar hiding the
> permission issue beneath a click on the red icon. Does anyone else have
> their Firefox on Mac OS X thinking their latest java is in fact an older
> version and therefore require user intervention to give permission?

You have got to be having a laugh aren't you? Haven't you seen: -
https://bugzilla.mozilla.org/show_bug.cgi?id=914690

Good to see Ben getting what's coming. If people want to work for Google then maybe they should. Or perhaps they already are :-(

    
    

    
  
This bug has run it's course, further discussions should be in appropriate bugs or other channels.

    
    

    
  
richard: Thanks, a disturbing turn of events indeed.

    
    

    
  
Perhaps this issue has come back? Java 8 Update 91, FF 45.0.2, Windows 10.  Unless I use setTimeout with a significant delay (over 3s), a call to one of the applet's public methods will not only not succeed (because it hasn't finished loading yet), but even after the applet has finished loading that same method will return with "not a function" permanently (until the page is reloaded).

In testing I made 3 public Java methods perform the same action. I called one immediately, one after a 500ms delay, and one after a 3s delay.  The first two methods are now dead and undefined, giving the "not a function" despite other methods on the applet working.  I can change the particular methods ordering and once again kill the ones called prior to the applet fully loading.

    
    

    
  
Jason, I think I confirmed your issue, but discovered another nuance. I am calling a method in a setTimeout loop on an applet so that it will work after the applet has finished loading. It works in IE11 and Firefox 46 on Mac, but Firefox 46 on Windows fails permanently, as you found. Here's the nuance: if you call the method with a different CASE in a subsequent call, it will work. For example:

applet.openFile("file") // fails
// after applet loads
applet.openFile("file") // still fails
applet.openFILE("file") // works (in any other case except "openFile") 

Same thing happens regardless of the case: e.g., if "openfile()" fails once, it fails always, but then "openFile()" will work. 

So, maybe there is a new bug in Firefox Windows, where it permanently fails to call the method of a certain case after it has failed once? Again, it works on FF Mac, same version. 

Ugh.

    
    

    
  
(In reply to jason.moran from comment #144)
(In reply to doug.arogos from comment #145)

I confirm the issue!
New Java, new firefox version => Error "[...] is not a function", even with "standard method" like "myApplet.isActive()"

My tests :
- Old Java ( < 1.8.0_91) , new firefox version => Cannot reproduce ; no error
- new Java (1.8.0_101), old firefox version (44.0 or newer) => Error "[...] is not a function"
- new Java (1.8.0_101), very old firefox version (37.0) => Cannot reproduce ; no error ; everything is fine again!


Maybe it has something to do with the "Firefox 42 liveconnect problem" mentioned here? http://www.oracle.com/technetwork/java/javase/8u91-relnotes-2949462.html
But I tried the workaround (in Firefox Developer Edition ; version 49.0a2 (2016-08-01)), and it does not change anything ; the problem is still present, with or without the "dom.ipc.plugins.enabled=false" parameter..

=> Question is : what can I do? It seems a mozilla problem, as this cannot be reproduced in Internet Explorer..
And this was not present in firefox 37, even with the newest Java version
Will there be a fix? Or is there an easy workaround to implement to avoid the problem?

Thanks,
  Julien.
Flags: needinfo?(gfritzsche)

    
    

    
  
This was closed with the reasons in comment 103. Furthermore, the preference "dom.ipc.plugins.enabled" is not supported anymore.

Given that we are dropping support for all plugins except Flash in March 2017 [1][2], i don't think this will get attention at this point.

[1] https://blog.mozilla.org/futurereleases/2016/07/20/reducing-adobe-flash-usage-in-firefox/
[2] https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Flags: needinfo?(gfritzsche)

    
  
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: