Closed Bug 748343 Opened 12 years ago Closed 12 years ago

remove support for "java" DOM object

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla15
Tracking Status
firefox15 + disabled

People

(Reporter: jaas, Assigned: jaas)

References

Details

(Keywords: addon-compat, dev-doc-complete, sec-want)

Attachments

(5 files, 1 obsolete file)

I'm considering removing access to Java from the DOM in Gecko. I'm specifically referring to the ability to access a global "java" object from JavaScript, I'm not referring to the general ability to script plugins via NPRuntime.

1. I don't believe this capability is good for the web, or that it should play a part in the future of the web. We don't and would not encourage its use by web developers.

2. Any exposure to Java (particularly via the Java NPAPI plugin, which is how it works now) exposes our users to Java security issues. We'd prefer to minimize this. This is an issue for all browser plugins, which is part of why we are also planning to make plugins click-to-play by default.

3. The existence of the features contributes to fragmentation on the web. Not all browsers support it, including Gecko on platforms without a Java plugin. Rather than have everyone add it I'd prefer to see everyone remove it.

4. We'd like to remove special status for technologies other than core web technologies. In the past we've worked with the Java plugin developers to make Java work the same as any other plugin. This would be an extension of those efforts.

5. This feature requires having and maintaining code in Gecko. While it isn't a huge maintenance burden, it does have a cost that seems increasingly not worth paying.
cc:ing dveditz as I know he would love to see this feature go too, as would I.
+1
Even Oracle (formerly Sun) discourages the use of the global "java".
http://jdk6.java.net/plugin2/liveconnect/#DEPRECATED_FUNCTIONALITY
Keywords: dev-doc-needed
Assignee: nobody → joshmoz
Can you guys not implement #2 for this fix for now?
Specifically, the "click-to-play by default" won't be good experience for users who need java to display their contents inside the browser.

For the rest of the changes, do we (Oracle) need to modify java plugin to work with it?

It would be good if there's a nightly build for us to try when the fix is ready so that we can fix issues (if any) before the FF version with this fix is released.
(In reply to Calvin Cheung from comment #4)
> Can you guys not implement #2 for this fix for now?
> Specifically, the "click-to-play by default" won't be good experience for
> users who need java to display their contents inside the browser.

Click to play is still being discussed, please see https://wiki.mozilla.org/Opt-in_activation_for_plugins which is frequently updated - IMO it's better discussed on mozilla.dev.security as it isn't directly related to this bug
(In reply to Calvin Cheung from comment #4)

> For the rest of the changes, do we (Oracle) need to modify java plugin to
> work with it?

You may be able to remove some code from the Java plugin, but you shouldn't need to modify the Java plugin to make anything work with this change. We simply won't instantiate a "dummy" instance of the Java plugin for use by the DOM.

> It would be good if there's a nightly build for us to try when the fix is
> ready so that we can fix issues (if any) before the FF version with this fix
> is released.

When you see this bug get fixed you can test the fix with the official Firefox nightly build a day or two later.
Attached patch fix v1.0 (obsolete) — Splinter Review
First cut at removal. Only compiled and tested on Linux so far.
Comment on attachment 619562 [details] [diff] [review]
fix v1.0

Requesting review, but I think we should wait to land this until we've cut a new ESR with this feature still in it.
Attachment #619562 - Flags: review?(jst)
Comment on attachment 619562 [details] [diff] [review]
fix v1.0

- In nsPluginHost::WritePluginInfo():

-      if (tag->mIsNPRuntimeEnabledJavaPlugin) {
+      // This used to depend on whether or not we had an npruntime-enabled
+      // Java plugin but we don't care any more, we just assume we do.
+      if (true) {

Might as well just remove that if check then. :)

r=jst with that.
Attachment #619562 - Flags: review?(jst) → review+
Attached patch fix v1.1Splinter Review
Address jst's review comment. Here is a try server run:

https://tbpl.mozilla.org/?tree=Try&rev=3d49ed0dc6ba

I'm still debating whether to land this now or wait for Firefox 17.
Attachment #619562 - Attachment is obsolete: true
FF 17? you mean FF16?
(In reply to Olli Pettay [:smaug] from comment #11)
> FF 17? you mean FF16?

I meant FF 17. I think most remaining users of this feature are probably good candidates for ESR, and FF 17 is the next time we cut a new one.

I think I'm going to try to land this for FF 15 though (perhaps today). I can always back it out if it's too problematic, but I suspect it'll be fine.
Attachment #619832 - Flags: superreview?(bugs)
If we can't land this now we could add a warning to the error console for each site that happens to trigger instantiation of this dummy plugin and ship that for a release or two to give site authors a chance to react before this feature is removed.
Comment on attachment 619832 [details] [diff] [review]
fix v1.1

Let's add a warning to Aurora.

nsWindowSH::NewResolve could use document's WarnOnceAbout
Attachment #619832 - Flags: superreview?(bugs) → superreview+
Blocks: 750661
Depends on: 750910
https://hg.mozilla.org/mozilla-central/rev/c3813fbb1c9a
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Depends on: 751641
Depends on: 733322
We never documented this in the first place (it wasn't even listed as existing at all), so all I've done is mention its removal on Firefox 15 for developers.
Attached file StringTest test case
I've attached 2 testcases to demonstrate that liveconnect call from javascript to applet's method is failing with the nightly 15.0a1 (2012-05-07) from http://nightly.mozilla.org/. I've tested with windows XP and JRE 7u4 (can be downloaded from java.com).

I've attached 2 testcases.
Both are liveconnect calls from javascript into applet's method.
The class files were compiled with jdk7.

StringTest - calls into applet's method upon "OnLoad"
JSJavaTest1 - calls into applet's method upon clicking on the javascript button.

My observation is that the java plugin module (npjp2.dll) wasn't loaded when running the above tests.
(In reply to Calvin Cheung from comment #20)

Can you file a new bug and note this as the potentially regressing bug?
(In reply to Josh Aas (Mozilla Corporation) from comment #21)
Can you file a new bug and
> note this as the potentially regressing bug?

I've filed the following bug:
    https://bugzilla.mozilla.org/show_bug.cgi?id=752746
Depends on: 752746
Is this literally a DOM object named "java", accessed as simply "java"? I ask because I can't find any documentation of such an object anywhere on MDN in order to update it.
No longer depends on: 752746
Yes, this is for the properties window.java and window.packages, and everything reachable from those properties.
OK, those are totally not documented, so I've just mentioned this change on Firefox 15 for developers.
There is still some leftover documentation at https://developer.mozilla.org/en/LiveConnect_Reference/Packages and https://developer.mozilla.org/en/LiveConnect_Reference/java . I don't know if anything links to these pages, but they do show up in MDN search results.
OK, fixed. I was not able to tell if those documents were related at all. :)
Keywords: sec-want
Blocks: 705415
Blocks: 768872
Blocks: 778073
No longer blocks: 778073
Depends on: 778073
(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #28)
> addon-compat per bug 778073.  Too bad
> https://developer-new.mozilla.org/en-US/docs/Java_in_Firefox_Extensions
> exists.  :(

That article has been flagged as obsolete, and features a note recommending that you not use Java in add-ons anymore.
This is a backout patch for beta, also backs out followup fixes and adds a warning.
Comment on attachment 648424 [details] [diff] [review]
beta backout plus warning v1.0

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch:
Attachment #648424 - Flags: approval-mozilla-beta?
Can we restore .java only for chrome code?
Also you can't add strings on beta ...
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #33)
> Also you can't add strings on beta ...

We don't care if those strings are localized or not.
But if you add strings to a .properties file on beta you'll set off a bunch of alarms and stuff.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #35)
> But if you add strings to a .properties file on beta you'll set off a bunch
> of alarms and stuff.

I think we need to accept that if it's true. We need this string. I assume we have ways to reach out to people about this not being a true alarm?
cc'ing Axel on this bug, and will also email to make sure that any alarms this trips are quelled.
Comment on attachment 648424 [details] [diff] [review]
beta backout plus warning v1.0

approving backout as needed for bug 778073, will email Axel (also cc'd on bug) to ensure we don't unnecessarily alarm localizers with this string landing on beta.
Attachment #648424 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I have moved the note about this being removed from Firefox 15 for developers to Firefox 16 for developers.
Grmpf, "We need this string" isn't really true, there are a plethora of alternatives to that. Sadly, making this calls on a travel day of mine breaks everything.

I'll work with Alexa and Lukas to educate them on the alternatives, and I think I will want to talk to jst about DOM deprecation warnings, we had a few now, and the ones I saw came with string freeze breaks.
Changing nsContentUtils::ReportToConsole to allow specifying the message text rather than the string name would be doable, so that we can opt to just hardcode the english string in the code for cases like these.
And what about developer who uses this functionality in their applications? I`m talking about xulrunner desktop app. I`m using java in it for the full functionality of smartcard. Is there any alternative ? (In reply to :Ms2ger from comment #1)
> +1
(In reply to Hamdi Hamdi from comment #43)

> And what about developer who uses this functionality in their applications?
> I`m talking about xulrunner desktop app. I`m using java in it for the full
> functionality of smartcard. Is there any alternative ? (In reply to :Ms2ger
> from comment #1)

Same solution - instantiate a Java instance of your own.
(In reply to Josh Aas (Mozilla Corporation) from comment #44)
> (In reply to Hamdi Hamdi from comment #43)
> 
> > And what about developer who uses this functionality in their applications?
> > I`m talking about xulrunner desktop app. I`m using java in it for the full
> > functionality of smartcard. Is there any alternative ? (In reply to :Ms2ger
> > from comment #1)
> 
> Same solution - instantiate a Java instance of your own.

Sorry but I didn't quite get that. How can I use global 'java' and 'Packages' from javascript when they deprecated and removed in future xulrunner releases ? Any examples/tutorials/refs ?
All the documentation at https://developer.mozilla.org/en-US/docs/JavaScript/Guide/LiveConnect_Overview still refers to the global java and package keywords. File a new bug or do you want to handle it here?

It's also the only page from https://developer.mozilla.org/en-US/docs/LiveConnect that doesn't 404.

Also seconding Hamdi Hamdi's concerns, I have an extension that uses the java keyword to create a classloader and thus access a local jar file using the approach in the deprecated 'Java in Firefox Extensions' article dealt with earlier in this bug, and am unsure how to go about updating this for FF15 at the end of the month. That's not really your problem though.
I'm not sure exactly on what level people aren't understanding my suggestion so I'll give some background.

Many plugins, including Java, are scriptable via an API called NPRuntime. This means that by implementing NPRuntime a plugin can allow JavaScript callers to call into it. Here is what that can look like:

  <embed id="plugin1" type="application/x-java-vm-npruntime" width="200" height="200"></embed>
  <script type="application/javascript">
    function doSomethingInPlugin() {
      var p1 = document.getElementById("plugin1");
      p1.functionExposedByPlugin();
    }
  </script>

The DOM-based Java access that was removed in this bug simply instantiated a Java plugin instance that belonged to the DOM and provided access to it via special DOM objects. Now we don't instantiate a Java instance for you to call into any more, and the shortcut objects don't do anything.

What I'm suggesting is that extensions do what the sample code above does - create your own Java plugin instance and call into it via its DOM object instead of "java" and "Packages". You don't have to do exactly what I did above (though I recommend using that MIME type) - it will also work to use object instead of embed, maybe even the applet tag (I don't know about that though). I believe Oracle provides some docs on Java plugin scripting for more information.
Thank you Josh. I've looked at http://jdk6.java.net/plugin2/liveconnect/ and everything is there.
Someone might want to consider writing a JSM that can be imported for extensions to get at a plugin instance conveniently. (might as well generalize it to load up any plugin) This would let this feature be accessible to extensions but not content and without adding anything to the DOM.
There's no particular reason it couldn't be a generic JS library that website authors could use also, assuming that you implemented .java in the same manner. I'm not sure how much java glue you actually need to do that.
Setting this to 'disabled' since it's been backed out of Firefox 15.
(In reply to Dave Garrett from comment #49)
> Someone might want to consider writing a JSM that can be imported for
> extensions to get at a plugin instance conveniently. (might as well
> generalize it to load up any plugin) This would let this feature be
> accessible to extensions but not content and without adding anything to the
> DOM.

Thans an idea. It would be great you leave it as JSM and we can use global through interfaces etc. It is real pain in the neck with those permission and policies when we use <embed> or <object> or the deprecated <applet>
(In reply to Josh Aas (Mozilla Corporation) from comment #0)

Hi, sorry I'm late to this conversation.

My add-on (https://addons.mozilla.org/en-US/firefox/addon/ads-fund-official-add-on/) relies completely on the java global object, and changing the add-on to use other methods would require a large amount of work.

In response to Josh Aas's original reasons to remove the java global object:

1. RE: ... good for the web ... future of the web ... web developers

This global object is window.java, and cannot be accessed by normal web developers, and is instead used for add-ons. For my add-on it provides access to a Java GUI and also byte-level TCP communication. This might seem strange in a HTTP-dominated browser system, but it allows my system to be particularly resilient to DoS attacks.

2. RE: security

As far as I can see, security is an issue regardless of this global object, and people can choose to uninstall/disable Java. Since add-ons are already moderated, the risk is presumably lower when accessing this object.

3. RE: fragmentation

I call it vitality.

5. RE: cost

Considering it determines the success of my add-on, the cost of you keeping some code in Gecko seems OK to me.


Thanks, and hopefully you will reconsider the removal of this aspect of the system.
(In reply to Tom Knight from comment #54)
> This global object is window.java, and cannot be accessed by normal web
> developers, and is instead used for add-ons.
Actually window.java was visible from Web pages.
(In reply to Masatoshi Kimura [:emk] from comment #55)
> (In reply to Tom Knight from comment #54)
> > This global object is window.java, and cannot be accessed by normal web
> > developers, and is instead used for add-ons.
> Actually window.java was visible from Web pages.

If that was true, what would stop someone from loading privileged code, just like my add-on.

If it's not the same object, why remove the privileged one?
(In reply to Tom Knight from comment #56)
> (In reply to Masatoshi Kimura [:emk] from comment #55)
> > (In reply to Tom Knight from comment #54)
> > > This global object is window.java, and cannot be accessed by normal web
> > > developers, and is instead used for add-ons.
> > Actually window.java was visible from Web pages.
> 
> If that was true, what would stop someone from loading privileged code, just
> like my add-on.

The same origin policy enforced by both Firefox and Java itself would stop loading of privileged code.
(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #57)
> (In reply to Tom Knight from comment #56)
> > (In reply to Masatoshi Kimura [:emk] from comment #55)
> > > (In reply to Tom Knight from comment #54)
> > > > This global object is window.java, and cannot be accessed by normal web
> > > > developers, and is instead used for add-ons.
> > > Actually window.java was visible from Web pages.
> > 
> > If that was true, what would stop someone from loading privileged code, just
> > like my add-on.
> 
> The same origin policy enforced by both Firefox and Java itself would stop
> loading of privileged code.

OK.

So although there are arguments against the access provided by window.java to web developers, they could still create the same access using the method in comment #47. This means that argument 2 in comment #0 isn't applicable, because the threat from Java is the same.

If you continue with this change, how would I create access to (applet [if necessary]) code in a bootstrapped add-on, so that I could then access static methods as in http://jdk6.java.net/plugin2/liveconnect/#PER_APPLET_PACKAGES ? Where do I put and specify the code that is loaded?
After I asked Jorge, he says you are 'definitely' applying this patch.

Are you really going to submit me to hours of hassle for those 5 speculative reasons?
Attached file javaPackageAccess.html
Tom - does this do the kind of thing you want to be able to do?
@David 
Many many thanks for that. I had no idea you could specify a java class without also supplying a jar file in an applet tag like that. Is this standard and a safe way of doing things? If so, it seems like it would be extremely straightforward to use this to create a java.net.URLClassLoader and array of java.net.URLs and thuis get all the functionality of https://developer.mozilla.org/en-US/docs/Java_in_Firefox_Extensions back. My initial playing around with your code indicates that this should be possible.

For the past week I have been struggling with trying to have my extension dynamically write an embed tag into the xul overlay with the correct file path to my jar(and finding it seems impossible to actually get any DOM elements with ids in a xul document), but if I can create a tag without specifying an archive, this should make things possible for me.

So is this a correct way of doing things, that is unlikely to break or be removed? The fact it uses the deprecated applet tag worries me, will Mozilla not be removing support for that eventually as well?
I don't know if it's a standard or safe way of doing this, but it seems like a logical extension of what's described in http://jdk6.java.net/plugin2/liveconnect/#PER_APPLET_PACKAGES.

If you want to avoid the applet tag, it looks like this also works:
<embed id="app" code="java.applet.Applet" type="application/x-java-applet">
(using object didn't work for me for some reason, but I didn't try too hard)

In terms of this functionality potentially being removed, my understanding is that this works because the java plugin exposes it, not because of anything firefox does.
What I've done in my xul overlay now is this:

<?xml version="1.0"?>
<overlay id="cipherdocs" 
        xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">		 
		 
<html:div name="appletDiv">
	<html:embed id ="cipherDocsApplet" type="application/x-java-applet;version=1.6" 
		code="java.applet.Applet"  pluginspage="http://java.com/download/"  MAYSCRIPT="true" width="0" height="0" />	 
</html:div>

<script type="text/javascript">
<![CDATA[
...
function onPageLoad(event) {

 //have to instantiate our own java instance
 var appletRef = document.getElementById("cipherDocsApplet");
 window.java = appletRef.Packages.java;
..
]]>
</script>


The mayscript attribute in the embed tag seems to be necessary to allow JSobjects to be properly converted when being passed to java. The pluginspage attribute can probably be omitted. I find I have to add the embed tag within a visible div or it will not be parsed.


My existing code had logic to find the jar file in the extension and bootstrap it and load classes from it and so on, and all this code now works _absolutely perfectly_ from what I can initially see. My extension seems to work, it can write to disk and make network connections and so on, so it has the correct permissions; it makes use of a library jar that has to be class loaded and this seems to be working properly. I will obviously do extensive testing, but for now I am very pleased!

Since the applet is part of the overlay on the main browser.xul window, there is one instance of the extension applet for each firefox window, which is what I want and is what I had previously, but worth bearing in mind for anyone reading this.
(In reply to David Keeler from comment #60)
> Created attachment 655062 [details]
> javaPackageAccess.html
> 
> Tom - does this do the kind of thing you want to be able to do?

My add-on is bootstrapped, so the tag will have to be inserted dynamically. So I don't know if that's possible.

Remember that even if that works (which would require around an hour to try), I have to adjust the code for this method, repackage, and resubmit, and deal with any additional work because of administration.
Dynamically adding the embed or applet tag doesn't work.

"java_instance.Packages" is undefined.


Code section:

       var java_instance = window.document.createElement("html:embed");
       java_instance.setAttribute("id", "adsfund_java_instance");
       java_instance.setAttribute("type", "application/x-java-applet");
       java_instance.setAttribute("code", "java.applet.Applet");
       java_instance.setAttribute("MAYSCRIPT", "true");
       java_instance.setAttribute("width", "0");
       java_instance.setAttribute("height", "0");
       window.document.getElementById("search-container").appendChild(java_instance);


Last line tries to trigger some kind of evaluation, but doesn't seem to cause anything.

If just embed rather than html:embed is used, no improvement.
(In reply to Tom Knight from comment #65)
>        var java_instance = window.document.createElement("html:embed");
createElementNS?
(In reply to Masatoshi Kimura [:emk] from comment #66)
> (In reply to Tom Knight from comment #65)
> >        var java_instance = window.document.createElement("html:embed");
> createElementNS?

Thanks, that allows the code to be loaded.

But now because the Java applet must (through testing trying to hide) be visible for code to be called, the UI layout is skewed.
(In reply to Tom Knight from comment #67)
> (In reply to Masatoshi Kimura [:emk] from comment #66)
> > (In reply to Tom Knight from comment #65)
> > >        var java_instance = window.document.createElement("html:embed");
> > createElementNS?
> 
> Thanks, that allows the code to be loaded.
> 
> But now because the Java applet must (through testing trying to hide) be
> visible for code to be called, the UI layout is skewed.

Another bug is that it won't work in multiple windows. I don't know why.
(In reply to Tom Knight from comment #68)
> (In reply to Tom Knight from comment #67)
> > (In reply to Masatoshi Kimura [:emk] from comment #66)
> > > (In reply to Tom Knight from comment #65)
> > > >        var java_instance = window.document.createElement("html:embed");
> > > createElementNS?
> > 
> > Thanks, that allows the code to be loaded.
> > 
> > But now because the Java applet must (through testing trying to hide) be
> > visible for code to be called, the UI layout is skewed.
> 
> Another bug is that it won't work in multiple windows. I don't know why.

The unloading behavior is different too. Which I also don't understand.
(In reply to Tom Knight from comment #69)
> The unloading behavior is different too. Which I also don't understand.

Ignore this one.
All problems solved. The code is available in version 1.4: https://addons.mozilla.org/en-US/firefox/addon/ads-fund-official-add-on/
I have a custom version of Selenium IDE that connects to Java which no longer works after this change.

I've tried adding

<div name="appletDiv">
    	<embed id ="cipherDocsApplet" type="application/x-java-applet;version=1.6" 
    		code="java.applet.Applet"  pluginspage="http://java.com/download/"  MAYSCRIPT="true" width="0" height="0" />	 
    </div>

to the various .xul files, but each time I try the below I get that appletRef is null:

var appletRef = document.getElementById("cipherDocsApplet");
     window.java = appletRef.Packages.java;


I have also tried adding it as Tom has posted:

var java_instance = window.document.createElementNS("http://www.w3.org/1999/xhtml","applet");
         java_instance.setAttribute("id", "adsfund_java_instance");
         java_instance.setAttribute("code", "java.applet.Applet");
         java_instance.setAttribute("width", "0");
         java_instance.setAttribute("height", "0");
       java_instance.setAttribute("flex", "1");
       
   var div = window.document.createElementNS("http://www.w3.org/1999/xhtml","div");
   var elementToAppendTo = window.document.getElementsByTagName("vbox")[0];
       elementToAppendTo.appendChild(div);
       div.appendChild(java_instance); 

  var date = new java_instance.Packages.java.util.Date();

But I get the following: TypetError:java_instance.Packages is undefined.

Finally I tried https://bug748343.bugzilla.mozilla.org/attachment.cgi?id=655062, adding the app element to my main xul file and getting it later, but that also gives me the same error: 'TypetError:app.Packages is undefined.'

What am I doing wrong?
Hello, I am trying to invoke the method printThis() of my applet HelloWorld.class from my firefox extension. When I execute my firefox extension is shown the next alert: 

TypeError: appletRef.printThis is not a function

This is the javascript code:

try{
        var java_instance = window.document.createElementNS("http://www.w3.org/1999/xhtml","applet");
	java_instance.setAttribute("id", "appHello");
	java_instance.setAttribute("code", "HelloWorld.class");
	java_instance.setAttribute("width", "0");
	java_instance.setAttribute("height", "0");
	java_instance.setAttribute("flex", "1");

	//Must be in div, otherwise layout is incorrect
	var div = window.document.createElementNS("http://www.w3.org/1999/xhtml","div");

	content.document.body.appendChild(div);
	div.appendChild(java_instance);

        var appletRef = content.document.getElementById("appHello");
	appletRef.printThis("Hello");

}catch(e){
	alert(e);
}	

I have the HelloWorld.class in the same folder than my overlay.xul and my javascript.js (content folder)

I have wrote the same code in a .html file and it works ok, but when I write the code in my firefox extension does not work.

What am I doing wrong? Any suggestion about this? 

Thanks in advance
With the upgrade to java 7 update 13, it seems that you no longer are able to use the code="java.applet.Applet". In the java console I get the following message:

basic: exception: Bad applet class name.
ExitException[ 3]java.lang.SecurityException: Bad applet class name
	at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

I tried google for it, but found nothing.

I tried creating my own applet inheriting from the standard applet, but couldn't find a way pointing it to the jar file in the extension. If I use an archive="chrome://....." I get an IOException:
        java.io.IOException: Cannot connect to chrome://...

Anyone found a workaround?
I have a workaround:

<html:div name="appletDiv">
	<html:embed id ="appletID" type="application/x-java-applet" 
		archive="https://mysite.com/applet.jar" code="Applet"  pluginspage="http://java.com/download/"  MAYSCRIPT="true" width="0" height="0" />	 
</html:div>

That applet.jar is nothing, it's just a single class called Applet that extends from java.Applet and doesn't do anything or declare anything. 

Basically, all you need is invoke the Java plugin and get a reference to a wrapped NSObject like what window.java used to be. Once you have that you can go off and create classloaders and other Java objects and proceed with loading your application. So to get that reference means having a valid applet-embedding tag. You used to be able to use the "code=java.applet.Applet" thing to create that valid tag. But I think Java 7u13 now explicitly forbids this(which seems like a good idea, it prevents an attacker being able to invoke the Java plugin from pure Javascript). So instead you need to properly create an applet tag with a jar file. Unfortunately there's no way I can find to do this with a local jar in the context of a Firefox extension. I tried "archive=applet.jar". but that results in a chrome:// URI being passed, which the plugin cannot handle. I tried using a direct file:// link to the applet file, but again, Java explicitly blocks using file:// URIs as links to applet jars for security reasons.

So the only solution I could see was to load the jar remotely, over http, so that's what I did. I'm not 100% pleased with this, but it's a workaround for now at least.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: