Closed Bug 754622 Opened 12 years ago Closed 11 years ago

[linux] Oracle/Sun Java jre1.7.0_04 and later does not work in SeaMonkey

Categories

(SeaMonkey :: Build Config, defect, P5)

x86
Linux

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.22

People

(Reporter: glgxg, Unassigned)

References

Details

(Keywords: relnote, Whiteboard: [workaround: comment 68])

User Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1
Build ID: 20120429012704

Steps to reproduce:

Today I updated two linux systems from Java (Oracle) 6 update 32 to Java
1.7.0.04 ((build 1.7.0_04-b20)) today. Java 1.7.0.04 is working fine on
the same systems with:

Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/15.0 Firefox/15.0a1
(Firefox Nightly)
Chromium: 18.0.1025.168 (Developer Build 134367 Linux) Ubuntu 11.04
Ephipany Web Browser 2.30.6

Other applications:
LibreOffice 3.5.3.2
LibreOffice 3.4.6

Java 7u4 is not working on SeaMonkey
Build identifier: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120429
Firefox/12.0 SeaMonkey/2.9.1
on either system. If Java is backed down to 6u32 then SeaMonkey (and
Prefbar 6.1 - Ping Manuel) pick it up fine. Tested using
<http://java.com>|Do I have Java?

SeaMonkey & Firefox Java plugin path:
Java(TM) Plug-in 1.7.0_04
    File: /opt/java/32/jre1.7.0_04/lib/i386/libnpjp2.so

Also tested:
o Clean 'test' profiles (created new SM profiles and did not use any
existing profiles).
o Prefbar 6.1 on Firefox - no issues, so I tested with the existing
SeaMonkey profiles with Prefbar turned off/on/uninstalled/newly reinstalled.
o Windows SM 2.9.1 versions + Java 7_4: WinXP & Win7 & all work fine.
o SeaMonkey 2.9.0 - no change.

No Java related files exist in ~/.mozilla. All versions of Firefox,
Firefox Nightlies, and SeaMonkey are run from ~/seamonkey (user home
directories). pluginreg.dat in SeaMonkey shows:

[INVALID]
/opt/java/32/jre1.7.0_04/lib/i386/libnpjp2.so:$
1334223796000:$

Whereas pluginreg.dat in Firefox shows:

libnpjp2.so:$
/opt/java/32/jre1.7.0_04/lib/i386/libnpjp2.so:$
:$
1334223796000:0:5:$
<a href="http://java.sun.com">Java</a> plug-in for NPAPI-based browsers.:$
Java(TM) Plug-in 1.7.0_04:$
36
0:application/x-java-vm:Java&#153 Plug-in::$
1:application/x-java-applet:Java&#153 Plug-in Applet::$
etc.

Note: I've renamed pluginreg.dat in SeaMonkey & let SM rebuild the data
- result is the same.

I've also tested with SeaMonkey versions:
2.10b1
2.11.a2
2.12a1
all fail. Note: 2.12a1 will *sometimes* recognise 1.7u4 & actually work on java.com. However when 12.a1 is closed the pluginreg.dat is again tagged with:
[INVALID]
/opt/java/32/jre1.7.0_04/lib/i386/libnpjp2.so:$
1334223796000:$
I do see the exact same behavior here with OpenSuSE 11.4.
Java 1.7.0_04 works fine with both, FF12 and FF13 beta, but does not
work with SM 2.9.1. I also have the [invalid] section in pluginreg.dat.
Java doesn't even show up in the Add-on manager under plugins.
FWIW Java 1.7.0_04 does work with SeaMonkey 2.9.1 on Windows.

Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1
Java(TM) Platform SE 7 U4
File: npjp2.dll    
Version: 10.4.0.22
Next Generation Java Plug-in 10.4.0 for Mozilla browsers

Verified Java Version
Congratulations!
You have the recommended Java installed (Version 7 Update 4).
@Jim Taylor: This bug is related to linux.
Platform: x86 Linux 
From Comment #1: "Windows SM 2.9.1 versions + Java 7_4: WinXP & Win7 & all work fine."
Summary: Sun Java jre1.7.0_04 does not work in SeaMonkey → [linux] Sun Java jre1.7.0_04 does not work in SeaMonkey
The same happens on Ubuntu 10.04 and SeaMonkey 2.9.1 build from repository UbuntuZilla
Hi! Try this. Shut down SeaMonkey and then delete blocklist.xml in your SeaMonkey profile. Wait 24 hours for the blocklist to be updated.

Lets see:
https://addons.mozilla.org/en-US/firefox/blocked/p80

"Who is affected?
All Firefox users who have installed the Java plugin, JRE versions below 1.6.0_31 or between 1.7.0 and 1.7.0_2."

So is 1.7.0_04 greater than 1.7.0_2 or less than?

The current regexp is:

<pluginItem  blockID="p80">
<match name="name" exp="\(TM\)" />
<match name="description" exp="[^\d\._]((0(\.\d+(\.\d+([_\.]\d+)?)?)?)|(1\.(([0-5](\.\d+([_\.]\d+)?)?)|(6(\.0([_\.](0?\d|1\d|2\d|30))?)?)|(7(\.0([_\.][0-2])?)?))))([^\d\._]|$)" />
<match name="filename" exp="(npjp2\.dll)|(libnpjp2\.so)" />                      <versionRange  severity="1"></versionRange>
Status: UNCONFIRMED → NEW
Component: General → Blocklisting
Ever confirmed: true
Product: SeaMonkey → addons.mozilla.org
QA Contact: general → blocklisting
Version: SeaMonkey 2.9 Branch → unspecified
I came across this & it seems to force a blocklist.xml generation.

> Components.classes['@mozilla.org/extensions/blocklist;1'].getService(Components.interfaces.nsITimerCallback).notify(null);

Paste above into Error Console, the Code: line, then press Evaluate.
Why is this in Blocklisting? Are you saying that the plugin is being blocked when it shouldn't be?
> Why is this in Blocklisting? Are you saying that the plugin is being blocked when it
> shouldn't be?

That's what several users are saying. I don't understand why 1.7.0_04 is allowed in Firefox but not in SeaMonkey given that the plugin blocklist code is in Toolkit so should be identical. Also the blocklist seems to be working properly with SeaMonkey on Windows and as far as I can tell the blocklist.xml is the same.

If you can suggest a better bugzilla component to move this to I'd be happy to do the move.
It sounds like a SeaMonkey bug to me. If the blocklist entry is the same, and the same block works correctly in Firefox and not in SM, it means something in the SeaMonkey Add-ons Manager code is causing the problem. The only other possibility I can think of is if we used an external library for regular expression processing and there was something different in the version SM uses...
> it means something in the SeaMonkey Add-ons Manager code is causing the problem.
Jorge, the Add-ons Manager code is in /toolkit/ so should be identical with Firefox.

> The only other possibility I can think of is if we used an external library for
> regular expression processing and there was something different in the version
> SM uses...

If the Linux users are using our official releases then it might be our build machines are using a different version of a system library compared to Firefox. If the Linux users are using SeaMonkey from their Linux repositories that would affect Firefox on Linux as well.
SeaMonkey, FireFox, Nightlies I am using/testing with are all from Mozilla - no distro versions are used. All are run from home directories;
~/seamonkey
~/firefox
~/FirefoxNightly

Regarding blocklist.xml:
- I've deleted the file entirely - no change (even after several days)
- I've substituted the SeaMonkey blocklist.xml with the Firefox version - no change
Added note: same issue on the 32bit and the 64bit linux versions of SeaMonkey. So whatever is causing the problem is common to the builds.
I just removed all Sun Java jre1.7 and installed OpenJDK7:

$ java -version
java version "1.7.0_03"
OpenJDK Runtime Environment (IcedTea7 2.1.1pre) (7~u3-2.1.1~pre1-1ubuntu2)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1
IcedTea-Web Plugin (using IcedTea-Web 1.2 (1.2-2ubuntu1))
 File: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
security.enable_java;true

Same issue - does not work with SeaMonkey (current profile and clean test profile w/no addons). Tested with Firefox and as with Sun Java jre1.7, everything works.
I can say that older versions such as Sun's Java 6 and also IcedTea NPR Web Browser Plugin (using IcedTea6 1.9.13 (6b20-1.9.13-0ubuntu1~10.04.1)) do work.
TL;DR: Firefox ignores the system java/jre and relies only on the mozilla-javaplugin.so symlink. But SeaMonkey requires both (system and mozilla-javaplugin.so).

A user in the mozilla.support.seamonkey reports:

@Jens: I did a bit of experimenting this morning and discovered (Ubuntu/Debian) that Mozilla Firefox (not the distro version) uses mozilla-javaplugin.so only, whereas SeaMonkey (not the distro version) does not & requires the system java also to be java-6-openjdk.

For example if I set my system jre to 1.7.0_04:

$ java -version
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode, sharing)

And set my mozilla-javaplugin.so to the same

$ ls -al /etc/alternatives/mozilla-javaplugin.so
lrwxrwxrwx 1 root root 45 2012-06-07 11:59 /etc/alternatives/mozilla-javaplugin.so -> /opt/java/32/jre1.7.0_04/lib/i386/libnpjp2.so

Firefox (13) picks up & accepts 1.7.0_04, SeaMonkey does not.

If I then set *only* mozilla-javaplugin.so to java-6-openjdk (leaving the system version set to 1.7.0_04):

$ sudo update-alternatives --config mozilla-javaplugin.so
There are 2 choices for the alternative mozilla-javaplugin.so (providing /usr/lib/mozilla/plugins/libjavaplugin.so).

  Selection    Path
  Priority   Status
------------------------------------------------------------
* 0            /opt/java/32/jre1.7.0_04/lib/i386/libnpjp2.so
   2000      auto mode
  1            /opt/java/32/jre1.7.0_04/lib/i386/libnpjp2.so
   2000      manual mode
  2            /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so
  1061      manual mode

Press enter to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so to provide /usr/lib/mozilla/plugins/libjavaplugin.so (mozilla-javaplugin.so) in manual mode.

Firefox 13 recognizes the change immediately and now uses java-6-openjdk (again leaving the system version set to 1.7.0_04) - SeaMonkey does not.

SeaMonkey *only* accepts java-6-openjdk if I set the system *and* the mozilla-javaplugin.so to java-6-openjdk:
====
$ sudo update-alternatives --config java
There are 4 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                      Priority   Status
------------------------------------------------------------
* 0            /opt/java/32/jre1.7.0_04/bin/java          2000      auto mode
  1            /opt/java/32/jre1.7.0_04/bin/java          2000      manual mode
  2            /usr/bin/gij-4.4                           1044      manual mode
  3            /usr/bin/gij-4.5                           1045      manual mode
  4            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      manual mode

Press enter to keep the current choice[*], or type selection number: 4 update-alternatives: using /usr/lib/jvm/java-6-openjdk/jre/bin/java to provide /usr/bin/java (java) in manual mode.
====

$ ls -al /etc/alternatives/mozilla-javaplugin.so
lrwxrwxrwx 1 root root 57 2012-06-07 12:03
/etc/alternatives/mozilla-javaplugin.so -> /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so

about:plugins (SeaMonkey):

IcedTea-Web Plugin (using IcedTea-Web 1.1.1 (1.1.1-0ubuntu1~11.04.2))
    File: /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so

Note: you do not have to shutdown & restart SeaMonkey to test; just clear all your caches & reload the about:plugins page.

So something is definately odd when Firefox ignores the system java/jre and relies only on the mozilla-javaplugin.so symlink. But SeaMonkey requires both (system and mozilla-javaplugin.so).
fwiw jre1.7.0_04 is LESS than jre1.7.0_2
fwiw: it doesn't matter. 

If you are referring to blocklist.xml, I've already demonstrated that the issue exists without a blocklist.xml, a substituted blocklist.xml, etc. If you are not, then please clarify what you are refering to with your comment "fwiw jre1.7.0_04 is LESS than jre1.7.0_2". 

I've already demonstrated that Firefox 13 works with;
jre1.7.0_04
java-6-openjdk
and now java version "1.7.0_b147-icedtea" (see below)

SeaMonkey does not. *Please* read the entire bug report.

====> 
Tested today on a Fedora 17 machine:

"I've just replicated the same in Fedora 17. First I installed openjdk &
tested with both Firefox(13) & SeaMonkey (2.10), and the result is
exactly the same as the above tests (works/works). I then did the same
with SeaMonkey 2.10, and the result is exactly the same as in the above
tests (fail/fail).

I then installed Sun Java JRE 1.7:

<http://www.if-not-true-then-false.com/2010/install-sun-oracle-java-jdk-jre-7-on-fedora-centos-red-hat-rhel/>

tested switch the java, and in this case, again, Firefox sword with
1.7.0_04, SeaMonkey did not. Switched them back to openJDK and
everything works in FireFox *and* SeaMonkey.

Note: I'me posting this from the Fedora 17 SeaMonkey:

Build identifier: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120429
Firefox/12.0 SeaMonkey/2.9.1

with openJDK:

IcedTea-Web Plugin (using IcedTea-Web 1.2 (fedora-2.fc17-i386))
    File: /usr/lib/IcedTeaPlugin.so

and tested with 'java.com':

Verified Java Version
Congratulations!
You have the recommended Java installed (1.7.0_b147-icedtea).

# uname -a
Linux Fedora17 3.4.0-1.fc17.i686 #1 SMP Sun Jun 3 07:16:04 UTC 2012 i686
i686 i386 GNU/Linux

$ java -version
java version "1.7.0_b147-icedtea"
OpenJDK Runtime Environment (fedora-2.1.fc17.6-i386)
OpenJDK Client VM (build 22.0-b10, mixed mode)

====
# alternatives --config libjavaplugin.so

There are 4 programs which provide 'libjavaplugin.so'.

  Selection    Command
-----------------------------------------------
 + 1           /usr/lib/IcedTeaPlugin.so
*  2           /usr/java/latest/jre/lib/i386/libnpjp2.so
   3           /usr/java/jre1.7.0_04/lib/i386/libnpjp2.so
   4           /usr/java/latest/lib/i386/libnpjp2.so

Enter to keep the current selection[+], or type selection number
====

====
# alternatives --config java

There are 3 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
 + 1           /usr/lib/jvm/jre-1.7.0-openjdk/bin/java
*  2           /usr/java/jre1.7.0_04/bin/java
   3           /usr/java/latest/bin/java

Enter to keep the current selection[+], or type selection number:
====
"
Summary: [linux] Sun Java jre1.7.0_04 does not work in SeaMonkey → [linux] Sun Java jre1.7.0_04/_05 does not work in SeaMonkey
Modified the Summary to include Sun Java jre1.7.0_04/_05. Updated my systems to Sun Java jre1.7.0_05-b05 and of course the same issue as with _04. Tested with SeaMonkey 2.9.1 & 2.10 (32 & 64bit versions).

Sun Java jre1.7.0_05-b05 works w/o issue with Firefox 13.
OK so this isn't a problem with the AMO block listing itself. Can someone recommend a more suitable product/component to move this to? Somewhere where people with the knowledge to fix this are more likely to notice this bug?
If this a general problem with the Toolkit part of the blocklist that only manifests in SeaMonkey, perhaps this is and Add-ons Manager problem.
Component: Blocklisting → Add-ons Manager
Product: addons.mozilla.org → Toolkit
QA Contact: blocklisting → add-ons.manager
What does about:plugins see 1.7.0_04 as? (name, filename, version, description)
FWIW, I don't think this is an issue with the Add-ons Manager or Blocklist service.
@Blair McBride: Have you read the initial comment and the subsequent comments in this bug report? 

re: Comment 21: about:plugins sees nothing - that is the entire point of this bug.

re: Comment 22: good observation.

I am sorry if I've misinterpreted your questions. But both appear to me as items already covered, and puzzle me why you are asking them.
Yea, sorry, I misread since there's so much talk about the blocklist here. Over to plugins.
Component: Add-ons Manager → Plug-ins
Product: Toolkit → Core
QA Contact: add-ons.manager → plugins
Problem still present with seamonkey version 2.10.1 and with java jre1.7.0_05
but this time at the startup of seamonkey I got the following error message (on the terminal)

LoadPlugin: failed to initialize shared library /***1***/java/jre1.7.0_04/lib/i386/libnpjp2.so [/***1***/java/jre1.7.0_04/lib/i386/libnpjp2.so: undefined symbol: _ZTIi]

(where I have replace with ***1*** the full path to the directory where I have the java installed).
google offers some hints that this is due to conflict between multiple versions of Java:

http://lists.fedoraproject.org/pipermail/users/2011-January/389881.html

"The problem seemed to be related to the combination of jre, icedtea and
quick java.  Uninstalling JRE and quickjava appears to have returned the
functionality, although there are many errors related to css and html
code which I think can be cleaned up (although this is related but not a
direct portion of this thread.)

Once quickjava and JRE were uninstalled, the firefox appears
functional."

http://forums.opensuse.org/english/get-help-here/applications/439597-java-plugin-firefox.html

"I would select number 2 on your list and ensure that you have installed java-1_6_0-sun-plugin. I would then get rid of the openjdk versions."

"I've removed openjdk using yast and deleted npwrapper.javaplugin.so in the Konsole:
# cd /usr/lib/browser-plugins/
# rm npwrapper.javaplugin.so
Now it seems to work."
@Phillip re Comment #26: 
Description:
"Java 1.7.0.04 is working fine on
the same systems with:

Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/15.0 Firefox/15.0a1
(Firefox Nightly)"

Comment #18
"Sun Java jre1.7.0_05-b05 works w/o issue with Firefox 13."

And note that I have (in Fedora, openSUSE, and Ubuntu 12.04 & 110.04) openjdk, icedtea & sun-jre installed. I've also demonstrated the appropriate methods to change between those. You can uninstall the others until you are blue in the face & the situation doesn't change regarding this SeaMonkey bug. 

@AnyFile: you are still pointing to '/java/jre1.7.0_04/lib/i386'. What is the output of:

ls -al /etc/alternatives/mozilla-javaplugin.so
java -version
Failure to resolve this bug is now IMO a security issue. With the recent issues regarding Java & openjdk browser plugins[1], SeaMonkey users may rely on outdated versions of openjdk ice-tea. Firefox correctly used the newly updated Java 7u7:

Java(TM) Plug-in 1.7.0_07
    File: /usr/lib/jvm/java-7-oracle/jre/lib/i386/libnpjp2.so
    Version: 
    Java plug-in for NPAPI-based browsers.

$ java -version
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) Client VM (build 23.3-b01, mixed mode)

SeaMonkey does not. 

[1]
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2012-4681>
Severity: normal → major
I just confirmed that this is still a problem with the latest Linux 32-bit SeaMonkey trunk nightly and 2.12.1 together with the latest Oracle Java 32-bit lib/i386/libnpjp2.so plugin version 1.7.0_07, that the output from comment 25 appears, and that the same plugin works with Firefox Nightly. AFAICS, Java 1.7.0_07 is currently not blocklisted (cf. https://addons.mozilla.org/en-US/seamonkey/blocked/)

However, TmoWizard reports on the German newsgroups that the latest Java version works with SM 2.12.1. His UA string says his SM version is Linux x86_64. Can anyone around confirm or refute that Java 1.7.0_07 works with Linux x86_64 SeaMonkey?
Summary: [linux] Sun Java jre1.7.0_04/_05 does not work in SeaMonkey → [linux] Oracle/Sun Java jre1.7.0_04 and later does not work in SeaMonkey
Nope. Doesn't work for me:
$ java -version
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
$ sudo update-alternatives --config mozilla-javaplugin.so
There is only one alternative in link group mozilla-javaplugin.so: /usr/lib/jvm/java-7-oracle/jre/lib/amd64/libnpjp2.so
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120826 Firefox/15.0 SeaMonkey/2.12 (note: I have 2.12.1 on another partition & the results are the same).

It does work with 64bit Firefox:
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Java(TM) Plug-in 1.7.0_07
    File: /usr/lib/jvm/java-7-oracle/jre/lib/amd64/libnpjp2.so
    Version: 
    Java plug-in for NPAPI-based browsers.
I was going to attach the blocklists for Firefox and SeaMonkey, but I ran into this error:

Bugzilla has suffered an internal error

Undefined subroutine Fh::slice
 at /data/www/bugzilla.mozilla.org/extensions/BrowserID/template/en/default/hook/account/auth/login-additional_methods.html.tmpl line 45

The Bugzilla maintainers have been notified of this error [#1347575849.11398].
(In reply to NoOp from comment #32)
> I was going to attach the blocklists for Firefox and SeaMonkey, but I ran
> into this error:

Which is BMO Bug 774198
It work here with:

$ java -version
java version "1.7.0_07"
OpenJDK Runtime Environment (IcedTea7 2.3.2) (7u7-2.3.2-1ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

$ update-alternatives --config mozilla-javaplugin.so
Es gibt nur eine Alternative in Link-Gruppe mozilla-javaplugin.so: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so

Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120909 SeaMonkey/2.12.1 Lightning/1.7 

Mike, TmoWizard
(In reply to Michael Speier from comment #34)
> OpenJDK Runtime Environment (IcedTea7 2.3.2) (7u7-2.3.2-1ubuntu0.12.04.1)

That's not Oracle's Java which this bug is about. No-one ever claimed here that the IcedTea plugin wasn't working. I do however take the blame for being not clear enough in the Known Issues section of recent Release Notes for SeaMonkey where I just wrote "The Java 7 plugin does not work with SeaMonkey". I'm going to correct that right now.
I don't know if it's relevant.
I have a JRE install from may 10 2010 of jre1.6.0_20 and used the libnpjp2.so plugin.
I removed the irrelevant plugin entries and saw java entries,
but they don't display in about:plugins of seamonkey 2.12.1 
User agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120909 Firefox/15.0.1 SeaMonkey/2.12.1
Build identifier: 20120909051705.

When checking on the site of oracle I get the message that java isn't installed, altho I have those entries.
Probably they aren't enabled.


Generated File. Do not edit.

[HEADER]
Version:0.15:$
Arch:x86-gcc3:$

[PLUGINS]

libnpjp2.so:$
/mnt/sdb1/applications/jre1.6.0_20.org/lib/i386/libnpjp2.so:$
:$
1271108384000:0:0:$
The next generation <a href="http://java.sun.com">Java</a> plug-in for Mozilla browsers.:$
Java(TM) Plug-in 1.6.0_20:$
34
0:application/x-java-vm:Java&#153 Plug-in::$
1:application/x-java-applet:Java&#153 Plug-in Applet::$
2:application/x-java-applet;version=1.1:Java&#153 Plug-in::$
3:application/x-java-applet;version=1.1.1:Java&#153 Plug-in::$
4:application/x-java-applet;version=1.1.2:Java&#153 Plug-in::$
5:application/x-java-applet;version=1.1.3:Java&#153 Plug-in::$
6:application/x-java-applet;version=1.2:Java&#153 Plug-in::$
7:application/x-java-applet;version=1.2.1:Java&#153 Plug-in::$
8:application/x-java-applet;version=1.2.2:Java&#153 Plug-in::$
9:application/x-java-applet;version=1.3:Java&#153 Plug-in::$
10:application/x-java-applet;version=1.3.1:Java&#153 Plug-in::$
11:application/x-java-applet;version=1.4:Java&#153 Plug-in::$
12:application/x-java-applet;version=1.4.1:Java&#153 Plug-in::$
13:application/x-java-applet;version=1.4.2:Java&#153 Plug-in::$
14:application/x-java-applet;version=1.5:Java&#153 Plug-in::$
15:application/x-java-applet;version=1.6:Java&#153 Plug-in::$
16:application/x-java-applet;jpi-version=1.6.0_20:Java&#153 Plug-in::$
17:application/x-java-bean:Java&#153 Plug-in JavaBeans::$
18:application/x-java-bean;version=1.1:Java&#153 Plug-in::$
19:application/x-java-bean;version=1.1.1:Java&#153 Plug-in::$
20:application/x-java-bean;version=1.1.2:Java&#153 Plug-in::$
21:application/x-java-bean;version=1.1.3:Java&#153 Plug-in::$
22:application/x-java-bean;version=1.2:Java&#153 Plug-in::$
23:application/x-java-bean;version=1.2.1:Java&#153 Plug-in::$
24:application/x-java-bean;version=1.2.2:Java&#153 Plug-in::$
25:application/x-java-bean;version=1.3:Java&#153 Plug-in::$
26:application/x-java-bean;version=1.3.1:Java&#153 Plug-in::$
27:application/x-java-bean;version=1.4:Java&#153 Plug-in::$
28:application/x-java-bean;version=1.4.1:Java&#153 Plug-in::$
29:application/x-java-bean;version=1.4.2:Java&#153 Plug-in::$
30:application/x-java-bean;version=1.5:Java&#153 Plug-in::$
31:application/x-java-bean;version=1.6:Java&#153 Plug-in::$
32:application/x-java-bean;jpi-version=1.6.0_20:Java&#153 Plug-in::$
33:application/x-java-vm-npruntime:::$

[INVALID]
Is there any workaround for this error ?
I have Plug-in 1.7.0_07 properly working in Firefox 15.0.1
But in Seamonkey 2.12.1 no luck.
None that I'm aware of. It's become a serious issue for me, and my customers. As a result I've switched all of my customers over to Firefox, Opera, other.
I can confirm, that the bug is indeed related to the blocklist. I could make the plugin visible by disabling the blocklist feature (in about:config set extensions.blocklist.enabled to false) and forcing a plugin rescan by deleting the file pluginreg.dat in the profile dir. After a restart of seamonkey the Java(TM) Plug-in 1.7.0_11 is available in about:plugins.
With some debugging I found out that in the JavaScript file nsBlocklistService.js the function _getPluginBlocklistState returns Ci.nsIBlocklistService.STATE_VULNERABLE_NO_UPDATE for the Java plugin. I think this result is wrong. Instead the function should return Ci.nsIBlocklistService.STATE_SOFTBLOCKED, to activate the click to play feature.

So something is wrong in the blocklist.xml file or its parsing. Unfortunately I'm quite new in Seamonkey development and I don't know how to debug Javascript code during the startup of the browser. So someone with more experience should look into this.
Priority: -- → P5
Thank you for your report. I've looked at the blocklist.xml more closely and I see that there are some differences with the Firefox version. For example the following entries are missing from SeaMonkey:

      <pluginItem  blockID="p119">
      <match name="name" exp="Java\(TM\) Plug-in 1\.(6\.0_(\d|[0-2]\d?|3[0-2])|7\.0(_0?([1-4]))?)([^\d\._]|$)" />            <match name="filename" exp="libnpjp2\.so" />                                    <versionRange  severity="1">
                                <targetApplication  id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
                              <versionRange  minVersion="0.1" maxVersion="17.*" />
                          </targetApplication>
                  </versionRange>
                  </pluginItem>

      <pluginItem  blockID="p132">
      <match name="name" exp="Java\(TM\) Plug-in 1\.7\.0(_0?([5-6]))?([^\d\._]|$)" />            <match name="filename" exp="libnpjp2\.so" />                                    <versionRange  severity="1">
                                <targetApplication  id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
                              <versionRange  minVersion="0.1" maxVersion="17.*" />
                          </targetApplication>
                  </versionRange>
                  </pluginItem>

      <pluginItem  blockID="p210">
      <match name="name" exp="Java\(TM\) Plug-in 1\.7\.0(_0?7)?([^\d\._]|$)" />            <match name="filename" exp="libnpjp2\.so" />                                    <versionRange  severity="1">
                                <targetApplication  id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
                              <versionRange  minVersion="0.1" maxVersion="17.*" />
                          </targetApplication>
                  </versionRange>
                  </pluginItem>

If severity="1" then nsBlocklistService.js will return:
Ci.nsIBlocklistService.STATE_VULNERABLE_UPDATE_AVAILABLE
If severity="1" then nsBlocklistService.js will return:
Ci.nsIBlocklistService.STATE_VULNERABLE_NO_UPDATE
q.v. http://hg.mozilla.org/mozilla-central/annotate/2a8e243711a9/toolkit/mozapps/extensions/nsBlocklistService.js#l841

So why isn't SeaMonkey getting "p119", "p132", and "p210"?

I *think* "p119" covers 1.7.0.4 and since the severity="1" we should be getting STATE_VULNERABLE_UPDATE_AVAILABLE but aren't
Changing back the component per the latest comment.
Component: Plug-ins → Blocklisting
Product: Core → addons.mozilla.org
Setting assignee to jorgev as per IRC conversation.
Assignee: nobody → jorge
Summary: [linux] Oracle/Sun Java jre1.7.0_04 and later does not work in SeaMonkey → [linux] Oracle/Sun Java jre1.7.0_04 and later does not work in SeaMonkey (needs "p119", "p132", and "p210" added to the blocklist)
Whiteboard: [add "p119", "p132", and "p210" to blocklist]
Why is this bug focused on the Linux blocks? The Mac and Windows equivalents also don't include SeaMonkey, so I wonder if there's anything in the comments above that I'm missing.
(In reply to Jorge Villalobos [:jorgev] from comment #44)
> Why is this bug focused on the Linux blocks? The Mac and Windows equivalents
> also don't include SeaMonkey, so I wonder if there's anything in the
> comments above that I'm missing.

I'd say, just because it was reported on linux, feel free to fix the blocks on all platforms. Thx!
The block modifications are now staged. Please verify that they are working as expected.
(In reply to snfuchs from comment #40)
> I can confirm, that the bug is indeed related to the blocklist. I could make
> the plugin visible by disabling the blocklist feature (in about:config set
> extensions.blocklist.enabled to false) and forcing a plugin rescan by
> deleting the file pluginreg.dat in the profile dir. After a restart of
> seamonkey the Java(TM) Plug-in 1.7.0_11 is available in about:plugins.

Doesn't work for me. Disabled blocklisting through about:config, quit SM, removed pluginreg.dat, started SM. Still no Java in about:plugins. [SM trunk 20130228 nightly build, Oracle JRE 1.7.0_15 - shows up in FF Nightly but not SM]

I don't think this is related to blocklisting. Unfortunately I don't know how to investigate what the real problem is. I can see with strace that SM accesses libnpjp2.so, i.e. it successfully traverses the symlink chain from /usr/lib/mozilla/plugins down to the actual plugin binary inside the extracted JRE directory. But then I'm lost.
Did you see the plug-in on Firefox?
(In reply to Masatoshi Kimura [:emk] from comment #48)
> Did you see the plug-in on Firefox?

Assuming you're talking to me: Yes. Output from about:plugins in FF Nightly:

Java(TM) Plug-in 1.7.0_15

    File: libnpjp2.so
    Path: /opt/jre1.7.0_15/lib/i386/libnpjp2.so
    Version: 
    State: Enabled (STATE_VULNERABLE_NO_UPDATE)
    Java plug-in for NPAPI-based browsers.

With SM trunk: Nothing. Same situation inside the Add-ons Manager.

I also checked http://www.java.com/de/download/testjava.jsp: click-to-play on FF Nightly, plugin-needed on SM trunk.
(In reply to Jorge Villalobos [:jorgev] from comment #46)
> The block modifications are now staged. Please verify that they are working
> as expected.

Philip, can you test this?
Flags: needinfo?(philip.chee)
> Philip, can you test this?
Unfortunately I can only test on Windows.
Flags: needinfo?(philip.chee)
The blocks were staged for all platforms. Some cursory testing on Windows should be sufficient to push these changes to production.
I have installed Java(TM) Platform SE 7 U17 and I can confirm that this is not blocked by the blocklist.
extensions.blocklist.enabled == true
plugins.click_to_play == false

So this is enough to push the changes to production.

However, the original plaint was that the Java plugin with SeaMonkey on Linux wasn't working while the same versions of Java with SeaMonkey on Windows were working.
If the staged blocks are working correctly, Java 7 U 15 and below should be CTP blocked for all platforms, and Java 7 U 17 should not be blocked on any platforms, so the behavior should be consistent.
Please READ the entire bug report:

1. Oracle Java does not work in SeaMonkey Linux.
2. Oracle Java works in Firefox Linux.
3. Oracle Java works in SeaMonkey Windows. 
"Testing" Windows versions is not related to this issue, and is (IMO) a waste of time.
4. Openjdk versions of Java work in SeaMonkey Linux.
3. Blocklist has nothing to do with the issue. See comments 11 & 17 & 47.

Firefox:
Java(TM) Plug-in 1.7.0_17

    File: /opt/java/64/jre1.7.0_17/lib/amd64/libnpjp2.so
    Version: 
    Java plug-in for NPAPI-based browsers.

SeaMonkey:
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16
    Build identifier: 20130217200017

Java does NOT appear or work when the Oracle version is enabled.
$ java -version
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
$ ls -al /etc/alternatives/mozilla-javaplugin.so
lrwxrwxrwx 1 root root 46 Mar  7 11:06 /etc/alternatives/mozilla-javaplugin.so -> /opt/java/64/jre1.7.0_17/lib/amd64/libnpjp2.so
about:plugins - no java.

Switch to openjdk:
$ java -version
java version "1.7.0_15"
OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
$ ls -al /etc/alternatives/mozilla-javaplugin.so
lrwxrwxrwx 1 root root 64 Mar  7 12:56 /etc/alternatives/mozilla-javaplugin.so -> /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so

about:plugins (Firefox 19.0 Linux):
IcedTea-Web Plugin (using IcedTea-Web 1.2 (1.2-2ubuntu1.3))
    File: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
    Version: 
    The IcedTea-Web Plugin executes Java applets.

about:plugins (SeaMonkey Linux 2.16)
IcedTea-Web Plugin (using IcedTea-Web 1.2 (1.2-2ubuntu1.3))
    File: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
    Version: 
    The IcedTea-Web Plugin executes Java applets.

Note: I am travelling so I only have occasional/limited access to the internet & will not be able to respond to comments regarding this bug regularly.
Sorry, that I added to the confusion. My previous analysis in comment #40 was clearly wrong.

I think the problem is indeed NOT related to the blocklisting (It's still off in the traces below).
Note for proper testing: Don't forget to delete the pluginreg.dat, when you switch between builds.

What caused the confusion was, that with my local debug build (on Ubuntu 12.04) the Oracle Java Plugin works.
I get the following output:
*** LOG addons.xpi: startup
*** LOG addons.xpi: checkForChanges
*** LOG addons.xpi-utils: Opening database
*** LOG addons.xpi: No changes found
*** LOG addons.xpi: Loading bootstrap scope from /home/stefan/.mozilla/seamonkey/uau6ir6l.default/extensions/firebug@software.joehewitt.com.xpi
*** LOG addons.xpi: Calling bootstrap method startup on firebug@software.joehewitt.com version 1.10.3
*** WARN addons.xpi: Exception running bootstrap method startup on firebug@software.joehewitt.com: ReferenceError: FBTrace is not defined
*** LOG addons.xpi: Loading bootstrap scope from /home/stefan/.mozilla/seamonkey/uau6ir6l.default/extensions/de-DE@dictionaries.addons.mozilla.org
*** LOG addons.xpi: Calling bootstrap method startup on de-DE@dictionaries.addons.mozilla.org version 2.0.3
*** LOG addons.xpi: Loading bootstrap scope from /home/stefan/.mozilla/seamonkey/uau6ir6l.default/extensions/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
*** LOG addons.xpi: Calling bootstrap method startup on {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} version 2.2.3
++DOCSHELL 0x7fb197cd8c00 == 1 [id = 1]
++DOMWINDOW == 1 (0x7fb197cda4b8) [serial = 1] [outer = (nil)]
++DOMWINDOW == 2 (0x7fb197cdb8b8) [serial = 2] [outer = 0x7fb197cda4b8]
++DOCSHELL 0x7fb18ead3000 == 2 [id = 2]
++DOMWINDOW == 3 (0x7fb18ead4cb8) [serial = 3] [outer = (nil)]
++DOMWINDOW == 4 (0x7fb18ead60b8) [serial = 4] [outer = 0x7fb18ead4cb8]
LoadPlugin() /usr/lib/jvm/java-7-oracle/jre/lib/amd64/libnpjp2.so returned 7fb18e56e700
*** Blocklist::_loadBlocklistFromFile: blocklist is disabled
.....


On the nightly build (seamonkey-2.19a1.en-US.linux-x86_64.tar.bz2), however, the plugin cannot be loaded:
*** LOG addons.manager: Application has been upgraded
*** LOG addons.xpi: startup
*** LOG addons.xpi: checkForChanges
*** Blocklist::_loadBlocklistFromFile: blocklist is disabled
*** LOG addons.xpi-utils: Opening database
*** LOG addons.xpi: Add-on langpack-de@chatzilla.mozilla.org changed appDisabled state to true, userDisabled state to false and softDisabled state to false
*** LOG addons.xpi-utils: Updating add-on state
*** LOG addons.xpi: Add-on langpack-de@venkman.mozilla.org changed appDisabled state to true, userDisabled state to false and softDisabled state to false
*** LOG addons.xpi-utils: Updating add-on state
*** LOG addons.xpi: Add-on {972ce4c6-7e08-4474-a285-3208198ce6fd} modified in app-global
*** LOG addons.xpi: Add-on modern@themes.mozilla.org modified in app-global
*** LOG addons.xpi: Updating database with changes to installed add-ons
*** LOG addons.xpi-utils: Updating add-on states
*** LOG addons.xpi-utils: Writing add-ons list
LoadPlugin: failed to initialize shared library /usr/lib/jvm/java-7-oracle/jre/lib/amd64/libnpjp2.so [/usr/lib/jvm/java-7-oracle/jre/lib/amd64/libnpjp2.so: undefined symbol: _ZTIi]
.....

Conclusion: Local build on Ubuntu 12.04 works. Downloaded nightly from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/ fails with the error above.
> LoadPlugin: failed to initialize shared library /usr/lib/jvm/java-7-oracle/jre/lib/amd64/libnpjp2.so [/usr/lib/jvm/java-7-oracle/jre/lib/amd64/libnpjp2.so: undefined symbol: _ZTIi]

Hmm. What version is your libstdc++.so ?
(In reply to Philip Chee from comment #57)
> > LoadPlugin: failed to initialize shared library /usr/lib/jvm/java-7-oracle/jre/lib/amd64/libnpjp2.so [/usr/lib/jvm/java-7-oracle/jre/lib/amd64/libnpjp2.so: undefined symbol: _ZTIi]
> 
> Hmm. What version is your libstdc++.so ?

I have /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
So I don't know what version of libstdc++.so is on our Linux boxes and whether it has the necessary symbols
Can someone summarize what this bug here is now about? I tried to find something about Oracle Java not working in SeaMonkey on Linux. Now I found this bug here which seems to be about a lot of different issues. Given that it's in Blocklisting it's about blocklisting some Java versions because of ???. Maybe a new bug should be opened (if there is not already one) for non-working Oracle Java in SeaMonkey on Linux.
(In reply to Frank Wein [:mcsmurf] from comment #60)
> Can someone summarize what this bug here is now about?

In essence it's about current versions of the Oracle Java plugin not working with current SeaMonkey versions on Linux (while working with current versions of Firefox).

It was guessed that this was due to the plugin being blocklisted. This assumption drove the choice of Product/Component set for this bug. Now that the blocklist has been updated (I take it is has been?), the issue persists which suggests that it was not caused by the blocklist.

> Maybe a new bug should be opened (if there is not already one) for
> non-working Oracle Java in SeaMonkey on Linux.

Probably. If anything still needs to be done on the blocklisting front it can be done on this bug, while any further investigation concerning the actual problem would be done on the new bug (like releng checking libstdc++ versions used when building SM/FF, as suggested in the last few comments).
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #61)
> It was guessed that this was due to the plugin being blocklisted. This
> assumption drove the choice of Product/Component set for this bug. Now that
> the blocklist has been updated (I take it is has been?), the issue persists
> which suggests that it was not caused by the blocklist.

The blocks haven't been pushed live yet. I'll get to that in the coming days. I was also very confused about the direction this bug had taken.
The blocks for SM are now live. For information on what is or isn't blocked, you can refer to this page: https://wiki.mozilla.org/Blocklisting/PluginBlocks
(In reply to Jorge Villalobos [:jorgev] from comment #63)
> The blocks for SM are now live.

The problem persists (using JRE 7u17), so I think we can rule out blocklisting as the culprit by now. See comment 61 for my suggestion how to proceed.

I don't know much about things like libstdc++, but since it was mentioned here, FWIW I also have version 6.0.16 (though, unlike comment 58, my Kubuntu VM is pure 32-bit, like the SM nightlies).

Maybe interesting:

# ldd firefox
        linux-gate.so.1 =>  (0xb7768000)
        libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7734000)
        libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb772f000)
        libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7649000)
        libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb761d000)
        libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb75ff000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7455000)
        /lib/ld-linux.so.2 (0xb7769000)

# ldd seamonkey
        linux-gate.so.1 =>  (0xb77ba000)
        libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7786000)
        libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7781000)
        libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7754000)
        libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7736000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb758c000)
        /lib/ld-linux.so.2 (0xb77bb000)

Note the libstdc++.so.6 difference.
Jens, I think you may have found the issue. Using Joe Lesko's PPA build of SeaMonkey 17:

<https://launchpad.net/~joe-nationnet/+archive/seamonkey-dev>
https://launchpad.net/~joe-nationnet/+archive/seamonkey-dev/+packages
https://launchpad.net/~joe-nationnet/+archive/seamonkey-dev/+build/4462740

libstdc++.so.6 is included:

/usr/lib/seamonkey-2.17$ ldd seamonkey
	linux-vdso.so.1 =>  (0x00007fff13ff3000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8adc9e7000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8adc6eb000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8adc3ea000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8adc1cd000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8adbe0e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8adcc1b000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8adbbf7000)

Java works in this version:
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17
    Build identifier: 20130404021333
Java(TM) Plug-in 1.7.0_17
    File: /opt/java/64/jre1.7.0_17/lib/amd64/libnpjp2.so
    Version: 
    Java plug-in for NPAPI-based browsers.

$ java -version
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)

Java does NOT work in the Mozilla build:
$ md5sum seamonkey-2.17.en-US.linux-x86_64.tar.bz2
a7301e85eea60aca0bb88c9dbf686c88  seamonkey-2.17.en-US.linux-x86_64.tar.bz2
~/seamonkey/seamonkey$ ldd seamonkey
	linux-vdso.so.1 =>  (0x00007fffc7924000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdc85797000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdc85593000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdc85296000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdc85080000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdc84cc1000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fdc859e4000)

Notice that Joe's build does include libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8adc3ea000). See the buildlog for details:
<https://launchpad.net/~joe-nationnet/+archive/seamonkey-dev/+build/4462740/+files/buildlog_ubuntu-precise-amd64.seamonkey_2.17-0ubuntu1%7Eprecise_UPLOADING.txt.gz>
Ok, so the official linux builds link statically with libstdc++

See the lines following lines from comm-central/suite/config/mozconfigs/linux32/release:
export LDFLAGS="-static-libstdc++"
export HOST_LDFLAGS="-static-libstdc++"

If the version of the libstdc++ library on the build server is older than the version the java plugin was compiled with, the plugin will fail to load.

The ppa seamonkey seems to include its own mozconfig.in, which does not contain the above lines (see https://launchpadlibrarian.net/136034443/seamonkey_2.17-0ubuntu1~precise.diff.gz).

Official firefox builds link dynamically against libstdc++ (see result of ldd command above), as well.
Further evidence is that mozilla-central/browser/config/mozconfigs/linux32/release does not contain the above lines. I noticed however, that it contains the following additional lines 
# Avoid dependency on libstdc++ 4.5
ac_add_options --enable-stdcxx-compat

So the question is now, is it save to do: 
-export LDFLAGS="-static-libstdc++"
-export HOST_LDFLAGS="-static-libstdc++"
+# Avoid dependency on libstdc++ 4.5
+ac_add_options --enable-stdcxx-compat

on all files in
comm-central/suite/config/mozconfigs/linux32/*
and
comm-central/suite/config/mozconfigs/linux64/*

or will this break everything.
Remove '[add "p119", "p132", and "p210" to blocklist]' modification in the subject.
Summary: [linux] Oracle/Sun Java jre1.7.0_04 and later does not work in SeaMonkey (needs "p119", "p132", and "p210" added to the blocklist) → [linux] Oracle/Sun Java jre1.7.0_04 and later does not work in SeaMonkey
So a simple Hack to make Java running is to set the environment Variable LD_PRELOAD to load a dynamic version of libstdc++.

  export LD_PRELOAD='libstdc++.so.6'
  seamonkey

This works in my system with seamonkey.2.17, java.1.7.0_17, openSUSE 11.3.

(Thanks to all wizzards above! I'm very happy about this simple workaround.)
Whiteboard: [add "p119", "p132", and "p210" to blocklist] → [workaround: comment 68]
Component: Blocklisting → Build Config
Product: addons.mozilla.org → SeaMonkey
Version: unspecified → Trunk
jorgev, thanks so far! Callek, ewong, please take over.
Assignee: jorge → nobody
> So a simple Hack to make Java running is to set the environment Variable LD_PRELOAD to
> load a dynamic version of libstdc++.

>    export LD_PRELOAD='libstdc++.so.6'

So the mozconfig in all apps *except* for Suite do:

> 12 # Avoid dependency on libstdc++ 4.5
> 13 ac_add_options --enable-stdcxx-compat

Also we are the only Gecko app to do this:

> 15 export LDFLAGS="-static-libstdc++"
> 16 export HOST_LDFLAGS="-static-libstdc++"
(In reply to eduard.gode from comment #68)
> So a simple Hack to make Java running is to set the environment Variable
> LD_PRELOAD to load a dynamic version of libstdc++.
> 
>   export LD_PRELOAD='libstdc++.so.6'
>   seamonkey
> 
> This works in my system with seamonkey.2.17, java.1.7.0_17, openSUSE 11.3.

Confirmed (SM 2.18b1/2.19a2/2.20a1, same JRE, Kubuntu 12.04). Two things to note:

1. Better use "LD_PRELOAD=libstdc++.so.6 seamonkey" to limit the effect to SM. I'll update the release notes with this advice until SM itself gets fixed.

2. about:plugins and the Add-ons Manager only show accurate information if either pluginreg.dat is removed manually before startup or the profile had been used with a different SM version before (which triggers some migration hooks and probably deletes or recreates pluginreg.dat automatically).
Re Comment 68: Thanks!

Works for me. I put it in a shell file ('seamonkeyjava'):
code:

#!/bin/sh
#
  export LD_PRELOAD='libstdc++.so.6'
  seamonkey

and then run 'seamonkeyjava'.

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17
    Build identifier: 20130404021333

Java(TM) Plug-in 1.7.0_17
    File: /opt/java/64/jre1.7.0_17/lib/amd64/libnpjp2.so
    Version: 
    Java plug-in for NPAPI-based browsers.

As Jens pointed out, rename or delete pluginred.dat prior to running for the first time. Or, remove the blocking code from the existing pluginreg.dat file first. In my case:

'[INVALID]
/opt/java/64/jre1.7.0_17/lib/amd64/libnpjp2.so:$
1362136926000:$'
It looks like Bug 904485 might finally fix this for good. Need to see in which SeaMonkey version this change will happen, maybe in next version, at latest in SeaMonkey 2.23.
Depends on: 904485
Ok, so this bug should be fixed in SeaMonkey 2.22, we've made some changes how SeaMonkey is built. Those changes fix this bug here, too.
Leaving bug open for now, will probably close after the first official SeaMonkey 2.22 beta builds are out to test this. I already checked with a trunk nightly that this bug seems to be fixed.
Target Milestone: --- → seamonkey2.22
Thanks!

I've just updated to SeaMonkey 2.22 and this is be working for me.

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22
Build identifier: 20131028185648

Java(TM) Plug-in 10.45.2

    File: libnpjp2.so
    Path: /opt/java/64/jre1.7.0_45/lib/amd64/libnpjp2.so
    Version: 10.45.2
    State: Enabled
    Next Generation Java Plug-in 10.45.2 for Mozilla browsers

From java.com:
Verified Java Version
Completion checkmark
Congratulations!
You have the recommended Java installed (Version 7 Update 45). 

I recommend closing this bug as 'Fixed'.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.