Jaunty icedtea6-plugin doesn’t work in Firefox 3.5

I can confirm this bug.

As the icedtea6-plugin and openjdk-6-jre work with the 'standard' Jaunty Firefox 3.0.x this bug should be against the new, unsupported Universe package of Firefox-3.5.

I've starting investigating this issue. The most obvious thing to notice is that the icedtea6-plugin doesn't create the named pipes in ~/icedteaplugin/ as it should.

That would explain the subsequent failure of the assertion for the gio write 'channel != NULL'. Obviously the channel is NULL and is presumably the pipe firefox should be writing to to communicate back to the plugin.

Using debug information from icedtea the problem appears to stem from "Error: create process":

  result = manager->CreateInstanceByContractID (NS_PROCESS_CONTRACTID,
                                                nsnull,
                                                NS_GET_IID (nsIProcess),
                                                getter_AddRefs (applet_viewer_process));
  PLUGIN_CHECK_RETURN ("create process", result);

which is called during initialisation:

ICEDTEAPLUGIN_DEBUG=1 firefox-3.5

...

Initializing JVM...
ICEDTEA PLUGIN: get component manager
ICEDTEA PLUGIN: liveconnect
ICEDTEA PLUGIN: thread manager
ICEDTEA PLUGIN: Instance::StartAppletviewer
ICEDTEA PLUGIN: get component manager
ICEDTEA PLUGIN: create local file
ICEDTEA PLUGIN: init with path
../IcedTeaPlugin.cc:3858: Error: create process
ICEDTEA PLUGIN: Instance::StartAppletviewer return
../IcedTeaPlugin.cc:1666: Error: started appletviewer
ICEDTEA PLUGIN: Factory::Initialize return

I have the same problem. Someone found an issues for this bug ?

Same here. Hopefully this gets fixed soon - going from 3.5 back to 3.0 sucks!

This is a high-importance bug since any applet embedded in a web page can cause Firefox to spin the CPU at 100% until the entire Firefox process is killed.

The user has no control over the launching of a Java applet nor warning that a page contains one.

Now that firefox-3.5 takes over the /usr/bin/firefox symbolic link this becomes more invasive since any desktop shortcuts or links embedded in application configurations that expect to launch a working firefox-3.0 will launch firefox-3.5 instead.

As the Ubuntu Firefox-3.5 project doesn't have an upstream bug-tracker link defined I can't set it in this bug's header, so here's the link:

https://bugzilla.mozilla.org/show_bug.cgi?id=516671 " IcedTea/OpenJDK Java Plug-in fails; causes 100% CPU use"

It is registered against Mozilla Core -> Plugins.

In the upstream bug I've discovered the reason for this problem.

IcedTeaPlugin in the OpenJDK package is built against the xulrunner 1.9.0 headers and uses the nsIProcess ID from xulrunner 1.9.0: "9DA0B650-D07E-4617-...".

The problem is that xulrunner 1.9.1 has changed the Interface ID (IID) of the nsIProcess component (an additional member has been added to the interface) - it is now "D573F1F3-FCDD-4DBE-...".

As a result, when the current IcedTeaPlugin tries to create an nsIProcess component for Firefox 3.5, xulrunner 1.9.1 can't find the component and returns NS_NOINTERFACE.

I'm exploring whether IcedTeaPlugin could be patched to query the nsIProcess interface to select the correct IID to use, or else catch this error and try the newer IID before giving up.

When you say "upstream bug" what bug are you talking about?

The bug referred to in my comment #8 and linked against Mozilla Firefox.

I've got a relatively simply patch in the works, although its a slight kludge.

In IcedTeaPluginFactory::StartAppletViewer() it will check the run-time xulrunner platform version and choose the IID to request (from the one provided by the 1.9.0 headers, or the explicitly coded 1.9.1 IID).

It should make the patch about 8 lines if everything I've read up on, and checked with the xulrunner dev's on IRC, proves correct.

Confirmation that a trivial patch solves this issue.

ICEDTEAPLUGIN_DEBUG=1 firefox-3.5
...
ICEDTEA PLUGIN: Instance::StartAppletviewer
ICEDTEA PLUGIN: get component manager
ICEDTEA PLUGIN: create local file
ICEDTEA PLUGIN: init with path
ICEDTEA PLUGIN: create process
ICEDTEA PLUGIN: init process
ICEDTEA PLUGIN: clearing old input fifo (if any): /home/tj/.icedteaplugin/icedtea-appletviewer-to-plugin
ICEDTEA PLUGIN: creating input fifo: /home/tj/.icedteaplugin/icedtea-appletviewer-to-plugin
ICEDTEA PLUGIN: created input fifo: /home/tj/.icedteaplugin/icedtea-appletviewer-to-plugin
ICEDTEA PLUGIN: got confirmation that appletviewer is running
ICEDTEA PLUGIN: clearing old output fifo (if any): /home/tj/.icedteaplugin/icedtea-plugin-to-appletviewer
ICEDTEA PLUGIN: creating output fifo: /home/tj/.icedteaplugin/icedtea-plugin-to-appletviewer
ICEDTEA PLUGIN: created output fifo: /home/tj/.icedteaplugin/icedtea-plugin-to-appletviewer
ICEDTEA PLUGIN: run process
Listening for transport dt_socket at address: 8787
ICEDTEA PLUGIN: Instance::StartAppletviewer return
...

In summary, The Jaunty version of openjdk-6 IcedTeaPlugin is built against the xulrunner 1.9.0.x dev headers (which Firefox 3.0.x uses). IcedTeaPlugin creates an instance of nsIProcess using the Interface ID (IID) declared in those headers. The nsIProcess object then loads and manages the JVM in another process.

Firefox 3.5 uses xulrunner 1.9.1.x, which has 'unfrozen' the nsIProcess interface definition and consequently changed the IID. Therefore when xulrunner 1.9.1 is asked to create the nsIProcess object by IcedTeaPlugin it fails since the old xulrunner 1.9.0 IID doesn't exist.

I've patched IcedTeaPlugin.cc to query the IID of nsIProcess at run-time rather than use the build-time definition. I've tested the same IcedTeaPlugin.so with Firefox 3.0 and 3.5 and both work correctly, starting the applet.

I've found there is a subsequent exception once the Sun Java test applet is running which needs a separate investigation:

ICEDTEA PLUGIN: Instance::ConsumeMsgFromJVM
received message: instance 1 status exception: java.lang.StringIndexOutOfBoundsException: String index out of range: 8.
Processing complete
ICEDTEA PLUGIN: Instance::ConsumeMsgFromJVM return

However, other sophisticated Java applets are working fine on Firefox 3.5 now.

I will attach a patch and debdiff with the fix and publish a fixed version of openjdk-6 to my PPA.

Because it takes so long to build openjdk and its a lot of overkill for building just IcedTeaPlugin I'll also build just the IcedTeaPlugin.so for i386 and amd64 and host them where they can easily be tested by backing up the current shared object:

/usr/lib/jvm/java-6-openjdk/jre/lib/{i386,amd64}/IcedTeaPlugin.so

and replacing it with the new one.

please see
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-September/007246.html
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-September/007248.html

The patch is intended as a specific patch for the Ubuntu Jaunty (and related Debian) openjdk package since it is supposed to support the use of the IcedTeaPlugin in both Firefox-3.0 and Firefox-3.5, but being built against the xulrunner 1.9.0 headers, fails in respect of the nsIProcess IID as I describe.

In later packages of openjdk (Karmic, etc) this issue should no longer be a problem since the default Firefox will be 3.5 and xulrunner 1.9.1+, and the IcedTea/OpenJDK packages are similarly up to date and don't make use of xulrunner 1.9.0 headers.

This bug was fixed in the package openjdk-6 - 6b16-1.6.1-1ubuntu1

---------------
openjdk-6 (6b16-1.6.1-1ubuntu1) karmic; urgency=low

  * Fix dependency on the java bridge packages.
  * debian/rules: Conditionalize stuff so that the recent release
    is never mentioned.
  * Remove obsolete patches in debian/patches.
  * Rebuild on armel to fix up libffi for the soft float abi.
  * For jaunty builds, fix IcedTeaPlugin failure to start with xulrunner 1.9.1
    (LP: #359407).
    - debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff: Add.
    - debian/rules: Apply it for jaunty builds.
  * Use pulseaudio as default serviceprovider for
    javax.sound.midi.MidiSystem and javax.sound.sampled.AudioSystem.
    LP: #407299.

 -- Matthias Klose <email address hidden> Sat, 26 Sep 2009 16:01:48 +0200

i am not sure why openjdk would want to use the nsIProcess IID directly. Can you elaborate?

I just noticed that openjdk 6b16-1.6.1-1ubuntu3 freezes Firefox 3.5.4 (and 3.5.5 from the ppa) in Karmic in a reproducible manner whenever I try to open a site requiring java. The only hint I was able to find is the following line in .xsession-errors:

/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/../../bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Perhaps an error in the 64bit version?

I am using Jaunty 32-bit with Firefox 3.5 (3.5.7+nobinonly-0ubuntu0.9.04.1) from the Ubuntu Universe repository and OpenJDK/IcedTea (6b16-1.6.1-0jaunty1) from the OpenJDK PPA (https://launchpad.net/~openjdk/+archive/ppa). I have never had Sun JDK or GCJ installed on this system.

None of the Java applets I have tried work (for example, http://www.java.com/en/download/help/testvm.xml).

Prior to installing OpenJDK 1.6.x from the OpenJDK PPA (when I was using OpenJDK 1.4.x that came with the official Jaunty repositories) when I loaded a Java applet, Firefox would hang at 100% CPU and nothing but a grey box would appear in place of the applet. I would have to manually kill the Firefox process.

Now that I am using OpenJDK 1.6.x, Firefox does not hang upon attempting to load the applet, but still only shows the grey box. I can still do all other Firefox operations normally. I still get error messages on the terminal identical to those shown in this bug report. When I close Firefox, the Firefox process hangs, and I have to manually kill it before starting a new Firefox instance.

So from what I can see, the OpenJDK/IcedTea 1.6.x packages in the OpenJDK PPA do nothing for this bug except delay the hang until you attempt to close the Firefox instance. Can someone confirm whether simply adding the OpenJDK PPA and dist-upgrading to OpenJDK 1.6.x is enough to fix this? Do I have to do any extra voodoo like first remove and purge all of Firefox/OpenJDK/world? Do I have to manually delete any directories or symlinks? I have not done any manual mucking around with the Firefox or OpenJDK stuff, and was hoping that simply letting apt do the upgrade would be sufficient, but apparently it's not.

Launchpad Janitor wrote on 2009-09-26: #17
> This bug was fixed in the package openjdk-6 - 6b16-1.6.1-1ubuntu1
> ---------------
> openjdk-6 (6b16-1.6.1-1ubuntu1) karmic; urgency=low

Does this mean the bug was fixed in Karmic, but not in Jaunty (for which it was reported)?
I installed openjdk-6-jre (6b14-1.4.1-0ubuntu12) and icedtea6-plugin (6b14-1.4.1-0ubuntu12) from the current repository but there's still no java in Firefox 3.5/3.6 (in Firefox 3.0.8 it works.)
Karmic does not like my notebook, that's why I have to stick with Jaunty.
Are there any dependencies in Jaunty that prevent the fixed openjdk from being incorporated into the repository?

Is https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/452413 a duplicate of this?

Karmic icedtea6-plugin works on my 32-bit machine, but not my 64-bit one.

This bug was fixed in the package openjdk-6 - 6b18-1.8-4ubuntu3~9.04.2

---------------
openjdk-6 (6b18-1.8-4ubuntu3~9.04.2) jaunty-security; urgency=low

  * Upload to Jaunty

openjdk-6 (6b18-1.8-4ubuntu3) lucid-proposed; urgency=low

  * Update from the 1.8 branch.
  * Rebuild with fixed ant.
  * Disable building the shark based VM on armel.
  * Always build the ARM assembler interpreter in arm mode.

openjdk-6 (6b18-1.8-4) unstable; urgency=low

  * Update from the 1.8 branch.
    - Plugin and netx fixes.
    - Don't link the plugin against the libxul libraries. Closes: #576361.
    - More plugin cpu usage fixes. Closes: #584335, #587049.
    - Plugin: fixes AppletContext.getApplets().
    - Fix race conditions in plugin initialization code that were causing
      hangs when loading multiple applets in parallel.
  * Fix Vcs-Bzr location. Closes: #530883.
  * Search for unversioned llvm-config tool.
  * Don't set XFILESEARCHPATH and NLSPATH on startup. LP: #586641.
  * Fix chinese font metrics and prefer using 'WenQuanYi Micro Hei' font.
    LP: #472845.
  * Strip libjvm.so with --strip-debug instead of --strip-unneeded.
    LP: #574997.
  * Don't turn on the ARM assembler interpreter when building the shark
    VM.

openjdk-6 (6b18-1.8-3) unstable; urgency=low

  * Update from the 1.8 branch.
    - Plugin fixes. LP: #597714.
  * Add powerpcspe build fixes (Sebastian Andrzej Siewior). Closes: #586359.
  * Work around build failure on buildds configured with low ARG_MAX
    (Giovanni Mascellani). Closes: #575254.

openjdk-6 (6b18-1.8-2ubuntu2) maverick; urgency=low

  * Search for unversioned llvm-config tool.

openjdk-6 (6b18-1.8-2ubuntu1) maverick; urgency=low

  * Upload to maverick.

openjdk-6 (6b18-1.8-2) unstable; urgency=low

  * Update from the 1.8 branch.
    - Fix build on Hitachi SH. Closes: #575346.
    - Shark and Zero fixes.
  * Build shark using llvm-2.7.
  * Don't use shark to run the test harness when testing the shark build.
  * README.Debian: Add paragraph about debugging the IcedTea NPPlugin.

openjdk-6 (6b18-1.8-1) unstable; urgency=low

  * Upload to unstable.

openjdk-6 (6b18-1.8-0ubuntu1) lucid; urgency=low

  * Update IcedTea6 to the icedtea6-1.8 release.
  * Fix builds on Ubuntu/dapper and Debian/lenny.
  * On hppa, configure --without-rhino --disable-plugin.
  * Fix Hitachi SH configury. Closes: #575346.
  * Start a window manager when running the tests. Prefer metacity,
    as more tests pass with it.
  * Let XToolkit.isTraySupported() return true, if Compiz is running.
    Works around sun#6438179. LP: #300948.
  * Make <java_home>/jre/lib/security/nss.cfg a config file.
  * Fail in the configuration of the packages, if /proc is not mounted.
    java currently uses tricks to find its own shared libraries depending
    on the path of the binary. Will be changed in OpenJDK7. Closes: #576453.
  * Fix PR icedtea/469, testsuite failures with the NSS based security
    provider. LP: #556549.
  * Do not pass LD_LIBRARY_PATH from the plugin to the java process.
    While libnss3.so gets loaded from /usr/lib, the dependent libraries
    are loaded from MOZILLA_FIVE_HOME (See #561216 for the wrong firefox
    config). LP: ...

this doesn't need fixes in firefox. firefox-3.6 is now in jaunty and newer releases. the plugin works with this version of firefox