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:126.96.36.199) 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
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.
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.
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.
On Windows, or all platforms? We disabled OOPP Java on Windows, but not all platforms, in bug 603417.
I just checked this on OS X and it does not work. So it seems like it only works on Windows.
Did this use to work on platforms other than windows?
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
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 #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.
7 years ago
Created attachment 507339 [details] [diff] [review] 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.
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.
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?