563891 - ReferenceError: java is not defined in XUL window

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Axel Nennker]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre

TokenIssuer.initialize threw ReferenceError: java is not defined
document.location.href=chrome://infocard/content/cardManager.xul

Warning: reference to undefined property window.java
Source File: chrome://infocard/content/infocards.js
Line: 1000

Reproducible: Always

Steps to Reproduce:
1. Install the openinfocard add from the xpi that I will attach to this bug
2. Go to https://xmldap.org/relyingparty
3. Click on the image and the selector will start
4. Create a new self-issued card if you do not have one already
5. Double-click that (new) card

Actual Results:  
6. The selector stays open and there are the ReferenceError messages in the console.

Expected Results:  
The selector should close, a security token should be generated by using java and that token should be send to the relyingparty.

Sorry, I do not have a small test case and I guess that this behavior is triggered by some other code that is running before the onload handler of the XUL window is called. The error occurs in the onload handler of cardmanager.xul and the name of the handler cardManagerLoad. Anyway I think that window.java should be defined and functional whatever I do.

Comment 1

[Axel Nennker]

Actually there seems to be a short test.
I started Firefox3.7a5pre in a new profile, opened the console and typed in the code input field: alert(window.java)
Now the java console starts but the alert window shows the text "undefined"

Comment 2

[Axel Nennker]

alert(window.java) does not work in Firefox4.0b2 neither.
The output is still "undefined"; the java console starts.
The expected output is '[Java Package "java"]'.
This test works in 'Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6' but not in the betas.

Comment 3

[Urs Holzer]

I did some bisection in mozilla-central between revision 37923 and 43461. As test, I simply started Firefox, opened the console and typed java.lang in it. I considered an output like '[Java Package "java.lang"]' as good and an error complaining about java being undefined as bad.

As result I found out that the problem has probably been introduced by changeset
40566:f292d7bd2e93: Bug 556849 - '[OOPP] Reduce unnecessary HasProperty calls for plugin scriptable objects'. r=jst+josh+bsmedberg.

I hope this helps.

Comment 4

[Brian Fernandes]

Have the same experience as Axel on Windows 7 64bit with Firefox 4 beta 2 and beta 4 pre. Cannot port my extension (http://thegoan.com/firebible) to Firefox 4 until this issue is fixed.

Comment 5

[Benjamin Smedberg]

This is probably the same as bug 573180

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

This breaks all extensions that use Java. They're a small portion of the ecosystem, but we're still talking about dozens of fairly complex and popular add-ons.

Comment 7

[Avram Lyon]

For the record, this is being problematic for Zotero's word processor integration as well: https://www.zotero.org/trac/ticket/1738. For the purposes of the Zotero project, it'd be great to see this be fixed before 4.0 final. Apologies if this comes across as bugspam.

Comment 9

[thomas.comiotto]

The liveconnect spec suggests to use applets instead of the deprecated globals, because of classloader issues (there's one classloader per applet). 

The extensions that are currently broken could be changed to use applets for javascript to java communication. Problem is, applets need to be signed for elevated privileges and that's silly in the context of extensions that have elevated permissions anyway.

So what's needed is a convenient way to run applets from extensions with corresponding privileges .

Comment 10

[Franziskus Kiefer [:franziskus]]

Problem occurs also on Thunderbird 3.1.5 (on Ubuntu 10.10).
alert(window.java) returns "undefined". Same worked on 3.1.4.
As far as I know Thunderbird couldn't load Applets, so that's not really an alternative.

Comment 11

[Brian Fernandes]

This now *works* in 4.08pre! I've been using Minefield to test, not sure if this fix is in a Firefox beta build yet.

"javascript:alert(java)" in the address bar will now bring up a message box with the expected output and my extension which relies very heavily on Java works just fine.

Comment 12

[Benjamin Smedberg]

On Windows, or all platforms? We disabled OOPP Java on Windows, but not all platforms, in bug 603417.

Comment 13

[Brian Fernandes]

Just checked and this works on Windows, not on Linux, no idea about OS X. Tested 4.0b8pre on Ubuntu 9.04 and "javascript:alert(java)" does not bring up the expected message box and the Error Console logs a "java is not defined" error. I did verify that Java is correctly installed and accessible to the browser, other applets work.

Comment 14

[Dylan Barrell]

I just checked this on OS X and it does not work. So it seems like it only works on Windows.

Comment 15

[Johnny Stenback (:jst)]

Did this use to work on platforms other than windows?

Comment 16

[Brian Fernandes]

Yes, this worked just fine on Windows, Linux and OS X.

Comment 17

[Dylan Barrell]

(In reply to comment #15)
> Did this use to work on platforms other than windows?

Yes, we make extensive use of this on all platforms including OS X and Linux

Comment 18

[Tom Schmidt]

I also see this problem on the Solaris 10 release of Firefox 4.0b9 as well.  The simple URL of "javascript:alert(java)" fails with "java is not defined" in the Error Console.

I have javascript code that checks java properties using calls like "java.lang.System.getProperty('os.version') that worked fine with Firefox 3.X and earlier (and other browsers), but now fails with Firefox 4.  This bug may be fixed on Windows, but still needs fixed on Linux, Solaris, and other UNIX variants.

Comment 19

[Urs Holzer]

As Thomas noted, it would be good to use a Java applet instead and then make use of the new LiveConnect API (https://jdk6.dev.java.net/plugin2/liveconnect/). But if you want the applet to run with full privileges, it must be signed and the user's Java policy has to be updated. And even then, Java code called from JavaScript does run without privileges.

Therefore it would be good to have a simple way of elevating the privileges of a Java applet without signing it. I created a feature request for this: See bug 628047.

Comment 20

[Axel Nennker]

I am not sure what "Java code called from JavaScript does run without
privileges" means. My java code in the openinfocard addon e.g. writes to the filesystem, opens network connections and talks to my smartcard.
https://code.google.com/p/openinfocard/source/browse/trunk/firefox/modules/tokenissuer.jsm
I expect that Java code called from Javascript in an extension (! xul window) has all privileges of the extension.

Java called from website-javascript does run without privileges.

Java called from xul-window-javascript has all privileges.

Comment 21

[Urs Holzer]

(In reply to comment #20)
> I am not sure what "Java code called from JavaScript does run without
> privileges" means.

Java code of an _applet_ that is invoked from JavaScript via LiveConnect runs with the privileges of an unsigned applet.

Comment 22

[Urs Holzer]

An intermediate workaround is to set the preference
dom.ipc.plugins.java.enabled
to false. (One has to add this preference in about:config.)
It seems to work for me. However, I don't know what this does exactly and I do not know whether this has any unwanted effects! You have been warned.

Comment 23

[Dylan Barrell]

(In reply to comment #20)
> I am not sure what "Java code called from JavaScript does run without
> privileges" means. My java code in the openinfocard addon e.g. writes to the
> filesystem, opens network connections and talks to my smartcard.
> https://code.google.com/p/openinfocard/source/browse/trunk/firefox/modules/tokenissuer.jsm
> I expect that Java code called from Javascript in an extension (! xul window)
> has all privileges of the extension.
> 
> Java called from website-javascript does run without privileges.
> 
> Java called from xul-window-javascript has all privileges.

I need full privileges in my extension Java code too.

Comment 24

[Dylan Barrell]

(In reply to comment #22)
> An intermediate workaround is to set the preference
> dom.ipc.plugins.java.enabled
> to false. (One has to add this preference in about:config.)
> It seems to work for me. However, I don't know what this does exactly and I do
> not know whether this has any unwanted effects! You have been warned.

What does this workaround do?

Comment 25

[Urs Holzer]

(In reply to comment #24)
> What does this workaround do?

As I understand it, this preference is currently set in order to disable OOPP on some platforms, but not on Linux. (See also Bug 573180.)
OOPP runs plugins out of process. The idea is to prevent plugins from crashing the browser.

This preference is set in http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js where you also find a comment about the reason.

Comment 26

[Urs Holzer]

(In reply to comment #25)
> As I understand it, this preference is currently set in order to disable OOPP
> on some platforms, but not on Linux. (See also Bug 573180.)
> OOPP runs plugins out of process. The idea is to prevent plugins from crashing
> the browser.

Sorry, this was not really clear. I wanted to say, setting the preference to false deactivates OOPP.

Comment 28

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Force java in-process for all platforms, v1

Josh, Johnny, and I have decided to force the java plugin in-process for all platforms now.

Comment 29

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Johnny, this should block betaN, not final.

Comment 30

[Josh Aas]

Comment on attachment 507339 [details] [diff] [review]
Force java in-process for all platforms, v1

Please add a clarification to your comment that your assumption refers to the Java plugin as distributed by Oracle, or "standard" Java, something like that. IIRC, there are Java plugins for which this is not true and we just use MIME types to decide whether or not something is a Java plugin.

Comment 31

[Ben Turner (not reading bugmail, use the needinfo flag!)]

http://hg.mozilla.org/mozilla-central/rev/bdfa2b67da3e

Comment 32

[Steve Scott (pxbugz)]

Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre

Comment 33

[Georg Fritzsche [:gfritzsche]]

Ben, Josh, Johnny:
Was this only an issue with window.java? Support for this was removed in 748343, so i assume we can probably undo this?