Skip to main content

Applet/Liveconnect problems with newer versions of Firefox

15 replies [Last post]
billdavidson
Offline
Joined: 2008-05-20
Points: 0

I'm working with an old Java 1.1 Applet. The classes are loaded directly (not through a jar file) so there's no signing. This used to work fine in Firefox but recent versions of Firefox (2.0.0.13/14) don't seem to work. It works fine in IE7 with Microsoft Java or the Java 1.6 plugin. I've tried it with recent versions of Java 1.4.2, 1.5 and 1.6 as the plugin.

In Firefox, the applet loads, and the user can interact with it. However when it's time for the page to be done, some Javascript tries to get data out of the applet. When the Javascript calls a method in the applet, this shows up in the Java console trace:

liveconnect: JavaScript: calling Java system code
liveconnect: JavaScript: default security policy = http://myhost.mydomain.com
liveconnect: JavaScript: calling Java system code
liveconnect: JavaScript: default security policy = http://myhost.mydomain.com
liveconnect: JavaScript: calling Java system code
liveconnect: JavaScript: default security policy = http://myhost.mydomain.com
liveconnect: JavaScript: calling Java system code
liveconnect: JavaScript: default security policy = http://myhost.mydomain.com
...[same messages keep repeating]...

It can go on like that for hours if I let it. What do these messages mean?

Thinking it might be an applet security thing, I tried wrapping all of the applet class files in a jar file and signed it (and removed the old class files just in case) but that didn't change the problem (BTW, still worked in IE7). I cleared by browser cache and restarted the server. No change. I've spent hours searching in Google but if anything, that has made me more confused.

Also, earlier in the Java console output at the end of the applet loading, I got this message:

liveconnect: JavaScript: UniversalJavaPermission enabled

That implies to me that Javascript should have full access to Java objects but as near as I can tell, that Javascript call to the Java method never happens. I have some System.out.println()'s in there and they come out in the console with IE7 but not in Firefox.

Any ideas?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
billdavidson
Offline
Joined: 2008-05-20
Points: 0

> Now I do have some good news. The accidental
> workaround we found was to access an applet method in
> the window onload() event and trigger the messages.
> We added an applet call there for a completely
> separate reason but all of a sudden the applet
> wasn't hanging for 15-20 seconds the first time a
> LiveConnect call was made, and having the applet
> call in the onload event doesn't seem to freeze the
> browser at all (making me wonder if it happens on a
> different thread).

Interesting. I will explore that.

> This may tie into the server differences, if pages
> load faster off the new server. I'm not really sure.

I'm convinced that there is some sort of network server issue. My current hypothesis is that there is something different about the network configuration of the new servers and the old servers and that there is something broken in the network code of the plugin that can't handle the new network configuration. The new plugin+FF3 has fixed this network problem and IE7+any plugin seems to do the networking right too.

I was trying to analyze the HTTP header differences with the "Live HTTP Headers" extensions to FF. Guess what? Nothing related to applets shows up. Apparently the plugin handles all HTTP interaction for applets on its own without using the HTTP code of the browser. Unfortunately, the Java Console trace only show the get commands and the cookies -- not showing the rest of the HTTP headers.

The HTTP headers may be irrelevant if it's some issue with reverse DNS or some other thing broken in the network code.

demonduck
Offline
Joined: 2008-03-14
Points: 0

I feel your pain.

I doubt any sort of work around exists. I think a lot of people have tried and failed.

And I know exactly where you are coming from WRT: having "civilians" upgrade their plugin and/or FF. When toasters fly...

billdavidson
Offline
Joined: 2008-05-20
Points: 0

> You can ignore the repeating messages; that's a side
> effect of the old Java Plugin design.

But what do they mean?

> Can you track down the last build of FireFox 2 where
> it worked?

I suppose I can try to track down old releases and install them.

> Might be worth reporting to Mozilla,
> although they may not care with FireFox 3 right
> around the corner.

Maybe. However, forcing all of our customers who use Firefox to upgrade to FF3-Beta and Java 1.6.0_10-Beta doesn't seem attractive.

> Incidentally, if you install FF3 and JRE 6u10 beta
> there's a completely new Java Plugin that may or may
> not resolve the issue.

Hmmm. That does seem to work. It's not really an attractive option though. This is a internet sales application. Making people upgrade before they can buy something is not an attractive option.

One other thing I've noticed. I don't seem to have the problem when I'm serving from an old 32-bit Redhat server (7.0 release 1). I have the problem from a new 64-bit Redhat server (5Server release 5.1.0.2). It seems odd that it would be the server though given that it works fine with IE7 from either.

andrewherron
Offline
Joined: 2008-04-03
Points: 0

Ah this thread brings back memories of trying to support FireFox 1.5 back when Sun made no claim whatsoever about FireFox support :)

You can't predict when it will hang. The only solution is to not support FireFox, which is what my company did until we were satisfied that a specific build of FireFox with a specific build of Java doesn't crash. FireFox 2 is usually fairly well behaved, but it wouldn't surprise me if they broke it by accident.

Now, as for why the messages appear; this is a bit of a long story.

Under Internet Explorer, the plugin uses an ActiveX control. This makes it really easy for the browser to know exactly which methods are available on the applet and everything's golden.

FireFox, of course, doesn't implement ActiveX. What they wound up with (and it sounds like this was a late-night hack) is a bunch of Reflection code to analyse the applet and expose all the methods it contains to JavaScript. For a JApplet that's a crapload of methods, even if you don't add any, which is why there are so many messages. Because it's so expensive they also perform this Reflection until the first time you attempt to access an applet method, which is why it freezes at that point.

Now I do have some good news. The accidental workaround we found was to access an applet method in the window onload() event and trigger the messages. We added an applet call there for a completely separate reason but all of a sudden the applet wasn't hanging for 15-20 seconds the first time a LiveConnect call was made, and having the applet call in the onload event doesn't seem to freeze the browser at all (making me wonder if it happens on a different thread).

This may tie into the server differences, if pages load faster off the new server. I'm not really sure.

demonduck
Offline
Joined: 2008-03-14
Points: 0

>
> Now I do have some good news. The accidental
> workaround we found was to access an applet method in
> the window onload() event and trigger the messages.
> We added an applet call there for a completely
> separate reason but all of a sudden the applet
> wasn't hanging for 15-20 seconds the first time a
> LiveConnect call was made, and having the applet
> call in the onload event doesn't seem to freeze the
> browser at all (making me wonder if it happens on a
> different thread).
>
> This may tie into the server differences, if pages
> load faster off the new server. I'm not really sure.

Very interesting! Given that FF2 is going to be around for a long time, I think I will give your method a try on my problem pages.

That's a call to *ANY* method right? So I could be a call to just a dummy method or a method that updates the status bar right?

Thanks in advance -- if it works :-)

andrewherron
Offline
Joined: 2008-04-03
Points: 0

> That's a call to *ANY* method right? So I could be a
> call to just a dummy method or a method that updates
> the status bar right?

Our method just sets an internal variable, and then if the applet has finished loading does some extra work.

billdavidson
Offline
Joined: 2008-05-20
Points: 0

Sadly, calling a java method from the javascript onload event method just cause the page to hang FF2 immediately for me.

andrewherron
Offline
Joined: 2008-04-03
Points: 0

That's very strange, we have no issues with our applet in FF2:
http://www.ephox.com/products/editlive/demo/start.html (shameless plug ;) )

> I was trying to analyze the HTTP header differences
> with the "Live HTTP Headers" extensions to FF. Guess
> what? Nothing related to applets shows up.
> Apparently the plugin handles all HTTP interaction
> for applets on its own without using the HTTP code
> of the browser. Unfortunately, the Java Console
> trace only show the get commands and the cookies --
> not showing the rest of the HTTP headers.
>
> The HTTP headers may be irrelevant if it's some issue
> with reverse DNS or some other thing broken in the
> network code.

As far as I know, the original plugin was slightly different between IE and FF but yes, it completely bypasses the browser (or at least the level that FF plugins can hook into).

What you want is a HTTP Sniffer - the effetech one at the top of google is ok (the trial is fully functional).
http://www.google.com.au/search?q=http+sniffer

billdavidson
Offline
Joined: 2008-05-20
Points: 0

We've got it working.

After analyzing the servers, we noticed that the new servers did not have reverse DNS lookup configured. We got it configured and now it works.

I'm still seeing the "default security policy" messages in the Java console but they're going by very quickly (they used to go slow) and the code goes through and works.

Apparently FF2+any plugin depends upon reverse DNS. IE+any plugin and FF3+1.6.0_10 do not.

pepone
Offline
Joined: 2005-03-13
Points: 0

I using firefox 3.5.3 and Java 1.6.0.15 and still see this problem, when i access my applet in a local server by it's ip address.

After reading that post i tried access by server name and the applet begins to work, still seem lot of repeated messages like

liveconnect: JavaScript: default security policy = http://venus
liveconnect: JavaScript: calling Java system code

This seems only a problem in FF linux FF in Windows and OSx doesn't show this problem.

Any ideas what cause this ? seems more a FF issue than a Java one

Cheers,
José

andrewherron
Offline
Joined: 2008-04-03
Points: 0

You can ignore the repeating messages; that's a side effect of the old Java Plugin design.

Can you track down the last build of FireFox 2 where it worked? Might be worth reporting to Mozilla, although they may not care with FireFox 3 right around the corner.

Incidentally, if you install FF3 and JRE 6u10 beta there's a completely new Java Plugin that may or may not resolve the issue.

demonduck
Offline
Joined: 2008-03-14
Points: 0

> You can ignore the repeating messages; that's a side
> effect of the old Java Plugin design.
>
> Can you track down the last build of FireFox 2 where
> it worked? Might be worth reporting to Mozilla,
> although they may not care with FireFox 3 right
> around the corner.
>
> Incidentally, if you install FF3 and JRE 6u10 beta
> there's a completely new Java Plugin that may or may
> not resolve the issue.

This has been a long standing and very annoying bug for at least the last 2 years. SUN and Mozilla have been pointing fingers at each other about this for at least that long.

And don't waste your time reporting it. It's a known problem.

We are being told that the next gen plugin and FF3 fix the problem.

billdavidson
Offline
Joined: 2008-05-20
Points: 0

> This has been a long standing and very annoying bug
> for at least the last 2 years. SUN and Mozilla have
> been pointing fingers at each other about this for at
> least that long.

And Microsoft rejoices!

> And don't waste your time reporting it. It's a known
> problem.

Sigh.

Do you know what the messages mean?

> We are being told that the next gen plugin and FF3
> fix the problem.

Great. Trying to get people who can barely use email to upgrade their Java and FF (both to beta versions) so they can buy something from my company is not an attractive option. Right now, their workarounds are to use IE or to not use our spiffy seat selection applet and let the web site select it for them -- losing one of our cooler features.

billdavidson
Offline
Joined: 2008-05-20
Points: 0

BTW, thanks to both of you for responding -- even though there doesn't seem to be a good answer available.

billdavidson
Offline
Joined: 2008-05-20
Points: 0

One other thought that I had.

Is it possible for Javascript to predict that this is going to happen? Once Javascript calls the Java method, the browser is effectively hung and there's nothing to do but kill it.

If there was some way for the Javascript to know the call to Java is going to fail before it does the call, it would at least allow me to do an alert and redirect so that I don't hang the customer's browser.