Closed Bug 563891 Opened 14 years ago Closed 13 years ago

ReferenceError: java is not defined in XUL window

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(blocking2.0 final+)

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: ignisvulpis, Assigned: bent.mozilla)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [softblocker][fx4-fixed-bugday])

Attachments

(1 file)

Force java in-process for all platforms, v1
1011 bytes, patch
jaas
: review+
Details | Diff | Splinter Review 
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.
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"
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.
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.
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.
This is probably the same as bug 573180
Status: UNCONFIRMED → NEW
blocking2.0: --- → final+
Component: General → Plug-ins
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → plugins
Assignee: nobody → bent.mozilla
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.
Severity: normal → major
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.
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 .
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.
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.
On Windows, or all platforms? We disabled OOPP Java on Windows, but not all platforms, in bug 603417.
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.
I just checked this on OS X and it does not work. So it seems like it only works on Windows.
Keywords: regression
Did this use to work on platforms other than windows?
Whiteboard: softblocker
Yes, this worked just fine on Windows, Linux and OS X.
(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
Whiteboard: softblocker → [softblocker]
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.
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.
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.
(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.
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.
(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.
(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?
(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.
(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.
Josh, Johnny, and I have decided to force the java plugin in-process for all platforms now.
Attachment #507339 - Flags: review?(joshmoz)
Johnny, this should block betaN, not final.
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.
Attachment #507339 - Flags: review?(joshmoz) → review+
http://hg.mozilla.org/mozilla-central/rev/bdfa2b67da3e
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Whiteboard: [softblocker] → [softblocker][fx4-fixed-bugday]
Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
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?
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: