Last Comment Bug 606737 - Java Applet: JSObject.getWindow(this) returns null
: Java Applet: JSObject.getWindow(this) returns null
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 1.9.2 Branch
: All Mac OS X
: -- normal with 9 votes (vote)
: ---
Assigned To: Steven Michaud [:smichaud] (Retired)
:
:
Mentors:
http://jnlp.dev.concord.org/test-japp...
: 608901 (view as bug list)
Depends on: 610525
Blocks: 598453
  Show dependency treegraph
 
Reported: 2010-10-23 19:50 PDT by Wei-ju Wu
Modified: 2011-01-12 07:58 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.13+
.13-fixed
.16+
.16-fixed


Attachments

Description Wei-ju Wu 2010-10-23 19:50:51 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11

It is not possible to call Javascript from an applet within Firefox on Mac OS X, because JSObject.getWindow(this) returns null. However, this works in Webkit browsers and Opera on Mac OS X as well as on Firefox on Ubuntu (with OpenJDK) and on Windows with the standard Oracle/Sun distribution.

Reproducible: Always

Steps to Reproduce:
1. Applet code (TestApplet.java):

import javax.swing.*;
import netscape.javascript.*;

public class TestApplet extends JApplet {
    public void init() {
        JSObject win = JSObject.getWindow(this);
        System.out.println("WINDOW IS: " + win);
    }
}

2. HTML page (index.html)

<html>
  <head><title>Test Applet</title></head>
  <body>
<applet id="testapplet" name="testapplet" codebase="." code="TestApplet.class" width="1" height="1"></applet>
  </body>
</html>

3. Compile Java file, e.g.

javac -classpath <path-to>/plugin.jar TestApplet.java

4. place TestApplet.class and index.html in the same directory
5. Load the HTML page in Firefox
Actual Results:  
WINDOW IS: null

Expected Results:  
WINDOW IS: [object DOMWindow]

My Java version:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)

Mac OS 10.6.4 Snow Leopard
Comment 1 Daniel 2010-10-25 04:32:18 PDT
I'm experiencing the same bug: JSObject.getWindow(this) returns 'null'.

This seems to be a problem related to http://localhost though. When I run the same code on a different domain (editing the /private/etc/hosts file), it works.
Comment 2 Wei-ju Wu 2010-10-25 05:43:30 PDT
Hi,
I can confirm that accessing it on a different domain gives me the window object. However, this just seems to move problem, the next call

JSObject jsDoc = (JSObject) win.getMember("document");

then returns null. And it still seems to be restricted to the Firefox/Mac OS X version.
Comment 3 Sebby Radar 2010-10-27 12:54:36 PDT
Same issue here, FF 3.5.14 release with Java 1.6.0_22.

Safari/MAC and FF/Windows with Java 1.6.0_22 not affected.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.14) Gecko/20101001 Firefox/3.5.14

       if (on_complete != null) {
            // call back javascript with status
            log("aptest callback (" + status + ", " + return_param_1 + ")");
            JSObject main_window = JSObject.getWindow(this);
            if (main_window == null) {
                System.out.println("aptest could not get browser main_window, JSObject.getWindow() returned null, this is going to fail");
                System.out.println("aptest java cannot call javascript functions in this browswer");
            }
            try {
                String[] args = new String[2];
                args[0] = status;
                args[1] = return_param_1;
                main_window.call(on_complete, args);
            }
            catch (Exception e) {
                System.out.println("aptest on_complete callback exception, " + e.getMessage());
                e.printStackTrace();
            }
        }

output on FF/Mac:

Java Plug-in 1.6.0_22
Using JRE version 1.6.0_22-b04-307-10M3261 Java HotSpot(TM) Client VM

MRJ Plugin for Mac OS X v1.0.1
[starting up Java Applet Security @ Wed Oct 27 12:25:56 PDT 2010]

aptest could not get browser main_window, JSObject.getWindow() returned null, this is going to fail
aptest java cannot call javascript functions in this browswer
aptest on_complete callback exception, null
java.lang.NullPointerException
	at aptest.start(aptest.java:181)
	at sun.applet.AppletPanel.run(AppletPanel.java:464)
	at jep.AppletFramePanel.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:680)
Comment 4 Sebby Radar 2010-11-05 06:36:43 PDT
Hmm, if I browse to http://browserspy.dk/java.php first, I see the following appear in the Java console.

<<< ProxyClassLoader: defined LiveConnectProxy class. >>>

My applet then works as long as the FF/JVM instance is running.  I see a ProxyClassLoader each time an applet is started.  It stops working after FF instance is closed.  Works again once I hit the magic page.  Something kicks in the LiveConnectProxy, not sure what it is.

Anyone else confirm?
Comment 5 Stephen Bannasch 2010-11-07 16:23:15 PST
I have an online demo of the original bug here: http://jnlp.dev.concord.org/test-japplet.html
Comment 6 Stephen Bannasch 2010-11-08 21:58:06 PST
I've added a bug report at the sourceforge tracker for the Java Plugin Project:

  http://sourceforge.net/tracker/?group_id=107955&atid=649116

Looking at the changesets in the source as FireFox progressed from 3.6.10 to 3.6.11 this one by Steven Michaud on Sep 24, 2010 stands out: 

Bug 598453 - r=josh a1.9.2.11=clegnitto.
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/06dbab839a94

The commit log message is obscure but the commit bumps these two artifacts from the Java Plugin Project (http://javaplugin.sourceforge.net/Readme.html):

  Java Embedding Plugin
  MRJ Plugin 1.0-JEP 

from version 0.9.7.3 to 0.9.7.4. 

Unfortunately the latest commit to the sourceforge CVS repository is from Mar 09 2010 and is for the v0.9.7.3 release. 

In addition the content on the page with Mozilla Bug 598453 is not visible to unauthorized developers. 

This makes me wonder if the update was a security fix.
Comment 7 Steven Michaud [:smichaud] (Retired) 2010-11-09 08:43:53 PST
This bug has the same cause as bug 607678 (though it isn't exactly a
dup).  The way you can tell is that both bugs cause lots of the
following message to appear in the system console:

MRJ Plugin JEP: JavaScript-to-Java LiveConnect failed --
  script principal has malformed origin!

I'm working on a fix for both bugs (bug 606737 and bug 607678) at bug
610525.  But that bug's a security bug, so it currently isn't
accessible.

(In reply to comment #6)

> This makes me wonder if the update was a security fix.

Yes, it fixed (or rather worked around) bug 589041 on OS X.

But bug 589041 (currently inaccessible) hasn't yet been completely
fixed on other platforms, so I haven't yet officially released JEP
0.9.7.4, or made its source code available.

And JEP 0.9.7.4, in working around bug 589041, caused breakage that
uncovered another, different security bug (bug 610525).  JEP 0.9.7.4's
breakage does "fix" (or rather work around) bug 610525, but not in an
acceptable fashion.  Hopefully my patch for bug 610525 will take care
of this.
Comment 8 Stephen Bannasch 2010-11-09 09:21:25 PST
Thanks for the update Steven.
 
Please let me know if I can help or test the patch for bug 610525 to see if it fixes the JSObject.getWindow issue. 

I have a project that we were planning to deploy to a school this week that uses an applet to collect data from a Vernier GoIO Temperature Probe and we need the applet => JavaScript communication bridge working.

Earlier we had asked the school to install FireFox because that had been the most stable browser for this application.
Comment 9 Steven Michaud [:smichaud] (Retired) 2010-11-09 09:36:36 PST
> Thanks for the update Steven.

You're welcome.

> I have a project that we were planning to deploy to a school this
> week

There's no way a fix could get into an FF release by that deadline.

But (by the way) I think there's an easy workaround:  Try calling an
applet method from JavaScript code before you call
JSObject.getWindow() from your applet.  Let us know your results.

> Please let me know if I can help or test the patch for bug 610525 to
> see if it fixes the JSObject.getWindow issue.

I hope to have a test build available later today.
Comment 10 Stephen Bannasch 2010-11-09 10:58:57 PST
Hey, that worked, thanks for the suggestion!

I have an online demo of the work-around here: http://jnlp.dev.concord.org/test-japplet2.html.

The page displays the Java code used to implement the work-around.

It displays the result of the JSObject.getWindow call back in the browser.

It works in FireFox 3.6.12 on the Mac.

The actual communication back to the browser doesn't complete successfully in Safari or Chrome on the Mac -- but that is a different problem.
Comment 11 Steven Michaud [:smichaud] (Retired) 2010-11-09 16:03:49 PST
Here's a test build made with my current patch for bug 610525.  Please try it and let us know your results.

http://people.mozilla.com/~stmichaud/bmo/firefox-3.6.13pre-bugzilla610525.en-US.mac.dmg
Comment 12 Stephen Bannasch 2010-11-10 01:38:04 PST
The Namroko bulid works fine with my test of the original bug:

http://jnlp.dev.concord.org/test-japplet.html

It also works with my test of a work-around.

http://jnlp.dev.concord.org/test-japplet2.html

Unfortunately it now generates the same security-related problem that Safari has with my actual application which is demoed here: 

http://jnlp.dev.concord.org/goio-temperature-graph.html

That particular program reads sensor data from a Vernier GoIO Temperature probe -- and the bug won't show up unless you have one plugged in.

Here's the line that throws the error:

https://github.com/concord-consortium/sensor-applets/blob/get-nar-as-resource/src/main/java/org/concord/sensor/applet/OTSensorApplet.java#L207

The Java console output is here: https://gist.github.com/670608

I'll try and put together a simpler case which causes the problem.

The temperature graphing app now works in FireFox 3.6.12 and Chrome and all the browsers I've tested on Windows.
Comment 13 Steven Michaud [:smichaud] (Retired) 2010-11-10 06:10:06 PST
> The Namroko bulid works fine with my test of the original bug:
>
> http://jnlp.dev.concord.org/test-japplet.html
>
> It also works with my test of a work-around.
>
> http://jnlp.dev.concord.org/test-japplet2.html

Glad to hear it!

> Unfortunately it now generates the same security-related problem
> that Safari has with my actual application which is demoed here:
>
> http://jnlp.dev.concord.org/goio-temperature-graph.html
>
> That particular program reads sensor data from a Vernier GoIO
> Temperature probe -- and the bug won't show up unless you have one
> plugged in.

This might be a bug in Apple's implementation of Sun/Oracle's JVM.

> I'll try and put together a simpler case which causes the problem.

Please do.  I don't have a Vernier GoIO Temperature probe, and I doubt
any other Mozilla developers have one, either :-)

When you do, please open a new bug.
Comment 14 Stephen Bannasch 2010-11-10 17:13:00 PST
My sensor applet application now works with the Namroko build (and Safari) -- it was a problem on my end.

However my sensor applet AND my second JApplet test (http://jnlp.dev.concord.org/test-japplet2.html) does NOT work on FireFox 4_b7 -- I've made a new issue: Bug 611183
Comment 15 Steven Michaud [:smichaud] (Retired) 2010-11-16 11:20:25 PST
This bug should now be fixed on the 1.9.2 and 1.9.1 branches by my patch for bug 610525, which landed yesterday on those branches.

Please check out the latest nightlies on those branches.

It's not yet fixed on the 1.9.0 branch (used by Camino 2.0.X).  But it should be once I get permission to land my fix for bug 610525 on the 1.9.0 branch.
Comment 16 Tim (fmdeveloper) 2010-12-29 14:01:14 PST
*** Bug 608901 has been marked as a duplicate of this bug. ***
Comment 17 Ángel Eduardo 2011-01-12 05:45:18 PST
Apparently, this is a duplicate of bug 606737, but it's still happening for me in 3.6.13 (working perfectly in Safari and Chrome), so I don't think this is working as it should yet.
Comment 18 Ángel Eduardo 2011-01-12 05:48:10 PST
Sorry, don't know what happened here, that comment was for another bug :?? (although it's still true that this isn't working for me, yet)
Comment 19 Steven Michaud [:smichaud] (Retired) 2011-01-12 07:58:34 PST
Ángel, please open a new bug on your problem, and CC me on it.  Be sure to include a test applet (with source code), and the html code you use to load it.

Quite apparently your bug is different from this one (bug 606737), which has now been fixed.  And there isn't enough information to say whether or not bug 608901 and bug 614282 are dups of this bug (and therefore also fixed).  So the best way to cut through the confusion is for you to open a new bug..

Note You need to log in before you can comment on or make changes to this bug.