Last Comment Bug 748343 - remove support for "java" DOM object
: remove support for "java" DOM object
Status: RESOLVED FIXED
: addon-compat, dev-doc-complete, sec-want
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla15
Assigned To: Josh Aas
:
Mentors:
Depends on: 733322 750910 751641 778073
Blocks: 705415 750661 768872
  Show dependency treegraph
 
Reported: 2012-04-24 06:59 PDT by Josh Aas
Modified: 2013-09-14 14:12 PDT (History)
30 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
disabled


Attachments
fix v1.0 (31.10 KB, patch)
2012-04-30 07:55 PDT, Josh Aas
jst: review+
Details | Diff | Splinter Review
fix v1.1 (31.65 KB, patch)
2012-04-30 21:42 PDT, Josh Aas
bugs: superreview+
Details | Diff | Splinter Review
StringTest test case (10.00 KB, application/octet-stream)
2012-05-07 16:28 PDT, Calvin Cheung
no flags Details
javascript calling applet's method test case (10.00 KB, application/octet-stream)
2012-05-07 16:29 PDT, Calvin Cheung
no flags Details
beta backout plus warning v1.0 (32.52 KB, patch)
2012-08-02 12:05 PDT, Josh Aas
lukasblakk+bugs: approval‑mozilla‑beta+
Details | Diff | Splinter Review
javaPackageAccess.html (296 bytes, text/plain)
2012-08-24 11:06 PDT, David Keeler [:keeler] (use needinfo?)
no flags Details

Description Josh Aas 2012-04-24 06:59:39 PDT
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.
Comment 1 :Ms2ger (⌚ UTC+1/+2) 2012-04-24 10:18:21 PDT
+1
Comment 2 Johnny Stenback (:jst, jst@mozilla.com) 2012-04-24 11:59:30 PDT
cc:ing dveditz as I know he would love to see this feature go too, as would I.
Comment 3 Masatoshi Kimura [:emk] 2012-04-24 17:58:49 PDT
+1
Even Oracle (formerly Sun) discourages the use of the global "java".
http://jdk6.java.net/plugin2/liveconnect/#DEPRECATED_FUNCTIONALITY
Comment 4 Calvin Cheung 2012-04-25 10:02:02 PDT
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.
Comment 5 Ian Melven :imelven 2012-04-25 11:23:33 PDT
(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
Comment 6 Josh Aas 2012-04-30 07:52:56 PDT
(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.
Comment 7 Josh Aas 2012-04-30 07:55:33 PDT
Created attachment 619562 [details] [diff] [review]
fix v1.0

First cut at removal. Only compiled and tested on Linux so far.
Comment 8 Josh Aas 2012-04-30 07:56:54 PDT
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.
Comment 9 Johnny Stenback (:jst, jst@mozilla.com) 2012-04-30 21:25:56 PDT
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.
Comment 10 Josh Aas 2012-04-30 21:42:32 PDT
Created attachment 619832 [details] [diff] [review]
fix v1.1

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.
Comment 11 Olli Pettay [:smaug] (vacation Aug 25-28) 2012-05-01 02:34:54 PDT
FF 17? you mean FF16?
Comment 12 Josh Aas 2012-05-01 07:35:17 PDT
(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.
Comment 13 Johnny Stenback (:jst, jst@mozilla.com) 2012-05-01 08:12:57 PDT
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 14 Olli Pettay [:smaug] (vacation Aug 25-28) 2012-05-01 12:19:20 PDT
Comment on attachment 619832 [details] [diff] [review]
fix v1.1

Let's add a warning to Aurora.

nsWindowSH::NewResolve could use document's WarnOnceAbout
Comment 15 Josh Aas 2012-05-01 13:49:27 PDT
pushed to mozilla-inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/c3813fbb1c9a
Comment 17 Eric Shepherd [:sheppy] 2012-05-07 10:04:22 PDT
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.
Comment 18 Calvin Cheung 2012-05-07 16:28:25 PDT
Created attachment 621778 [details]
StringTest test case
Comment 19 Calvin Cheung 2012-05-07 16:29:23 PDT
Created attachment 621779 [details]
javascript calling applet's method test case
Comment 20 Calvin Cheung 2012-05-07 16:32:59 PDT
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.
Comment 21 Josh Aas 2012-05-07 16:34:24 PDT
(In reply to Calvin Cheung from comment #20)

Can you file a new bug and note this as the potentially regressing bug?
Comment 22 Calvin Cheung 2012-05-07 16:59:43 PDT
(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
Comment 23 Eric Shepherd [:sheppy] 2012-05-08 04:59:21 PDT
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.
Comment 24 Johnny Stenback (:jst, jst@mozilla.com) 2012-05-08 10:19:24 PDT
Yes, this is for the properties window.java and window.packages, and everything reachable from those properties.
Comment 25 Eric Shepherd [:sheppy] 2012-05-09 08:46:12 PDT
OK, those are totally not documented, so I've just mentioned this change on Firefox 15 for developers.
Comment 26 Stuart Cook 2012-05-17 21:17:04 PDT
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.
Comment 27 Eric Shepherd [:sheppy] 2012-05-18 08:17:04 PDT
OK, fixed. I was not able to tell if those documents were related at all. :)
Comment 28 Boris Zbarsky [:bz] 2012-07-27 16:12:54 PDT
addon-compat per bug 778073.  Too bad https://developer-new.mozilla.org/en-US/docs/Java_in_Firefox_Extensions exists.  :(
Comment 29 Eric Shepherd [:sheppy] 2012-07-31 11:04:38 PDT
(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.
Comment 30 Josh Aas 2012-08-02 12:05:17 PDT
Created attachment 648424 [details] [diff] [review]
beta backout plus warning v1.0

This is a backout patch for beta, also backs out followup fixes and adds a warning.
Comment 31 Josh Aas 2012-08-02 12:06:37 PDT
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:
Comment 32 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-08-02 12:11:44 PDT
Can we restore .java only for chrome code?
Comment 33 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-08-02 12:12:20 PDT
Also you can't add strings on beta ...
Comment 34 Josh Aas 2012-08-02 12:49:00 PDT
(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.
Comment 35 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-08-02 13:09:29 PDT
But if you add strings to a .properties file on beta you'll set off a bunch of alarms and stuff.
Comment 36 Josh Aas 2012-08-02 15:36:39 PDT
(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?
Comment 37 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-02 17:25:50 PDT
cc'ing Axel on this bug, and will also email to make sure that any alarms this trips are quelled.
Comment 38 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-02 17:26:51 PDT
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.
Comment 39 Josh Aas 2012-08-03 08:55:07 PDT
Backed out on beta.

http://hg.mozilla.org/releases/mozilla-beta/rev/8f991bfecae8
Comment 40 Eric Shepherd [:sheppy] 2012-08-03 09:00:19 PDT
I have moved the note about this being removed from Firefox 15 for developers to Firefox 16 for developers.
Comment 41 Axel Hecht [pto-Aug-30][:Pike] 2012-08-03 09:39:20 PDT
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.
Comment 42 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-08-03 11:51:59 PDT
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.
Comment 43 Hamdi Hamdi 2012-08-06 03:00:56 PDT
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
Comment 44 Josh Aas 2012-08-06 04:39:36 PDT
(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.
Comment 45 Hamdi Hamdi 2012-08-06 05:53:26 PDT
(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 ?
Comment 46 Karl Reid 2012-08-07 05:14:19 PDT
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.
Comment 47 Josh Aas 2012-08-07 10:24:15 PDT
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.
Comment 48 Hamdi Hamdi 2012-08-07 12:51:23 PDT
Thank you Josh. I've looked at http://jdk6.java.net/plugin2/liveconnect/ and everything is there.
Comment 49 Dave Garrett 2012-08-07 12:52:04 PDT
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.
Comment 50 Benjamin Smedberg [:bsmedberg] 2012-08-07 14:27:14 PDT
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.
Comment 52 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-07 15:29:34 PDT
Setting this to 'disabled' since it's been backed out of Firefox 15.
Comment 53 Hamdi Hamdi 2012-08-10 02:12:25 PDT
(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>
Comment 54 Tom Knight 2012-08-20 09:14:49 PDT
(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.
Comment 55 Masatoshi Kimura [:emk] 2012-08-21 00:02:20 PDT
(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.
Comment 56 Tom Knight 2012-08-21 04:31:23 PDT
(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?
Comment 57 Johnny Stenback (:jst, jst@mozilla.com) 2012-08-21 09:26:09 PDT
(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.
Comment 58 Tom Knight 2012-08-21 10:35:47 PDT
(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?
Comment 59 Tom Knight 2012-08-24 10:36:25 PDT
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?
Comment 60 David Keeler [:keeler] (use needinfo?) 2012-08-24 11:06:04 PDT
Created attachment 655062 [details]
javaPackageAccess.html

Tom - does this do the kind of thing you want to be able to do?
Comment 61 Karl Reid 2012-08-24 11:25:53 PDT
@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?
Comment 62 David Keeler [:keeler] (use needinfo?) 2012-08-24 11:46:26 PDT
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.
Comment 63 Karl Reid 2012-08-24 12:08:50 PDT
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.
Comment 64 Tom Knight 2012-08-24 14:14:31 PDT
(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.
Comment 65 Tom Knight 2012-08-25 01:17:04 PDT
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.
Comment 66 Masatoshi Kimura [:emk] 2012-08-25 01:25:32 PDT
(In reply to Tom Knight from comment #65)
>        var java_instance = window.document.createElement("html:embed");
createElementNS?
Comment 67 Tom Knight 2012-08-25 02:44:06 PDT
(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.
Comment 68 Tom Knight 2012-08-25 03:03:47 PDT
(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.
Comment 69 Tom Knight 2012-08-25 03:34:52 PDT
(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.
Comment 70 Tom Knight 2012-08-25 06:26:18 PDT
(In reply to Tom Knight from comment #69)
> The unloading behavior is different too. Which I also don't understand.

Ignore this one.
Comment 71 Tom Knight 2012-08-25 11:45:58 PDT
All problems solved. The code is available in version 1.4: https://addons.mozilla.org/en-US/firefox/addon/ads-fund-official-add-on/
Comment 72 jamesfarrier 2012-11-04 20:01:20 PST
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?
Comment 73 aluchek 2012-11-21 07:16:50 PST
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
Comment 74 mera461 2013-02-03 14:19:32 PST
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?
Comment 75 Karl Reid 2013-02-05 15:49:57 PST
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.

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