Last Comment Bug 754622 - [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
Status: RESOLVED FIXED
[workaround: comment 68]
: relnote
Product: SeaMonkey
Classification: Client Software
Component: Build Config (show other bugs)
: Trunk
: x86 Linux
: P5 major with 5 votes (vote)
: seamonkey2.22
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 769956 821882 (view as bug list)
Depends on: 904485
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-12 17:42 PDT by NoOp
Modified: 2013-11-01 22:40 PDT (History)
24 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description NoOp 2012-05-12 17:42:47 PDT
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:$
Comment 1 Christian Riechers 2012-05-12 22:29:32 PDT
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.
Comment 2 Jim Taylor 2012-05-13 06:26:56 PDT
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).
Comment 3 NoOp 2012-05-13 10:17:28 PDT
@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."
Comment 4 CGP 2012-05-13 12:47:47 PDT
The same happens on Ubuntu 10.04 and SeaMonkey 2.9.1 build from repository UbuntuZilla
Comment 5 Philip Chee 2012-05-14 03:36:14 PDT
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>
Comment 6 therube 2012-05-14 09:21:24 PDT
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.
Comment 7 Jorge Villalobos [:jorgev] 2012-05-14 10:12:39 PDT
Why is this in Blocklisting? Are you saying that the plugin is being blocked when it shouldn't be?
Comment 8 Philip Chee 2012-05-14 10:36:06 PDT
> 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.
Comment 9 Jorge Villalobos [:jorgev] 2012-05-14 13:46:26 PDT
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...
Comment 10 Philip Chee 2012-05-15 02:43:35 PDT
> 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.
Comment 11 NoOp 2012-05-15 12:26:54 PDT
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
Comment 12 NoOp 2012-05-15 12:50:34 PDT
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.
Comment 13 NoOp 2012-05-17 14:22:45 PDT
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.
Comment 14 CGP 2012-05-17 20:45:42 PDT
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.
Comment 15 Philip Chee 2012-06-08 03:56:28 PDT
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).
Comment 16 Justin Wood (:Callek) 2012-06-10 19:39:52 PDT
fwiw jre1.7.0_04 is LESS than jre1.7.0_2
Comment 17 NoOp 2012-06-10 19:53:03 PDT
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:
====
"
Comment 18 NoOp 2012-06-13 16:56:59 PDT
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.
Comment 19 Philip Chee 2012-06-13 20:30:34 PDT
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?
Comment 20 Jorge Villalobos [:jorgev] 2012-06-14 10:29:05 PDT
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.
Comment 21 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-06-14 19:13:43 PDT
What does about:plugins see 1.7.0_04 as? (name, filename, version, description)
Comment 22 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-06-14 19:37:45 PDT
FWIW, I don't think this is an issue with the Add-ons Manager or Blocklist service.
Comment 23 NoOp 2012-06-14 19:58:35 PDT
@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.
Comment 24 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-06-14 21:32:37 PDT
Yea, sorry, I misread since there's so much talk about the blocklist here. Over to plugins.
Comment 25 AnyFile 2012-06-17 13:30:06 PDT
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).
Comment 26 Philip Chee 2012-06-17 21:26:36 PDT
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."
Comment 27 NoOp 2012-06-18 12:22:45 PDT
@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
Comment 28 Matthias Versen [:Matti] 2012-06-30 16:08:14 PDT
*** Bug 769956 has been marked as a duplicate of this bug. ***
Comment 29 NoOp 2012-08-31 12:51:18 PDT
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>
Comment 30 Jens Hatlak (:InvisibleSmiley) 2012-09-13 09:45:51 PDT
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?
Comment 31 NoOp 2012-09-13 15:33:06 PDT
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.
Comment 32 NoOp 2012-09-13 15:39:07 PDT
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].
Comment 33 Justin Wood (:Callek) 2012-09-13 22:04:03 PDT
(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
Comment 34 Michael Speier 2012-09-15 06:57:03 PDT
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
Comment 35 Jens Hatlak (:InvisibleSmiley) 2012-09-15 07:02:17 PDT
(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.
Comment 36 bugzilla 2012-10-01 14:01:44 PDT
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]
Comment 37 martin.suc 2012-10-03 05:14:23 PDT
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.
Comment 38 NoOp 2012-10-04 19:53:58 PDT
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.
Comment 39 Matthias Versen [:Matti] 2012-12-19 06:09:10 PST
*** Bug 821882 has been marked as a duplicate of this bug. ***
Comment 40 snfuchs 2013-02-03 08:26:53 PST
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.
Comment 41 Philip Chee 2013-02-04 09:29:36 PST
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
Comment 42 Masatoshi Kimura [:emk] 2013-02-04 23:17:01 PST
Changing back the component per the latest comment.
Comment 43 Philip Chee 2013-02-05 09:12:31 PST
Setting assignee to jorgev as per IRC conversation.
Comment 44 Jorge Villalobos [:jorgev] 2013-02-06 12:04:50 PST
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.
Comment 45 Justin Wood (:Callek) 2013-02-06 12:13:43 PST
(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!
Comment 46 Jorge Villalobos [:jorgev] 2013-02-22 13:19:42 PST
The block modifications are now staged. Please verify that they are working as expected.
Comment 47 Jens Hatlak (:InvisibleSmiley) 2013-03-02 16:23:54 PST
(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.
Comment 48 Masatoshi Kimura [:emk] 2013-03-02 16:31:36 PST
Did you see the plug-in on Firefox?
Comment 49 Jens Hatlak (:InvisibleSmiley) 2013-03-03 05:01:00 PST
(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.
Comment 50 Jorge Villalobos [:jorgev] 2013-03-05 14:55:14 PST
(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?
Comment 51 Philip Chee 2013-03-06 07:39:08 PST
> Philip, can you test this?
Unfortunately I can only test on Windows.
Comment 52 Jorge Villalobos [:jorgev] 2013-03-06 08:56:13 PST
The blocks were staged for all platforms. Some cursory testing on Windows should be sufficient to push these changes to production.
Comment 53 Philip Chee 2013-03-07 06:05:08 PST
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.
Comment 54 Jorge Villalobos [:jorgev] 2013-03-07 06:41:28 PST
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.
Comment 55 NoOp 2013-03-07 12:08:14 PST
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.
Comment 56 snfuchs 2013-03-07 15:04:50 PST
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.
Comment 57 Philip Chee 2013-03-08 08:38:41 PST
> 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 ?
Comment 58 snfuchs 2013-03-08 09:36:05 PST
(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
Comment 59 Philip Chee 2013-03-09 02:48:50 PST
So I don't know what version of libstdc++.so is on our Linux boxes and whether it has the necessary symbols
Comment 60 Frank Wein [:mcsmurf] 2013-04-03 01:32:08 PDT
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.
Comment 61 Jens Hatlak (:InvisibleSmiley) 2013-04-03 07:37:36 PDT
(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).
Comment 62 Jorge Villalobos [:jorgev] 2013-04-03 09:08:16 PDT
(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.
Comment 63 Jorge Villalobos [:jorgev] 2013-04-10 09:55:14 PDT
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
Comment 64 Jens Hatlak (:InvisibleSmiley) 2013-04-10 12:36:01 PDT
(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.
Comment 65 NoOp 2013-04-10 14:11:55 PDT
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>
Comment 66 snfuchs 2013-04-10 15:13:40 PDT
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.
Comment 67 NoOp 2013-04-10 21:32:32 PDT
Remove '[add "p119", "p132", and "p210" to blocklist]' modification in the subject.
Comment 68 eduard.gode 2013-04-10 22:28:39 PDT
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.)
Comment 69 Jens Hatlak (:InvisibleSmiley) 2013-04-10 23:34:37 PDT
jorgev, thanks so far! Callek, ewong, please take over.
Comment 70 Philip Chee 2013-04-11 10:36:55 PDT
> 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++"
Comment 71 Jens Hatlak (:InvisibleSmiley) 2013-04-11 13:23:06 PDT
(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).
Comment 72 NoOp 2013-04-11 18:28:18 PDT
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:$'
Comment 73 Frank Wein [:mcsmurf] 2013-08-22 13:38:24 PDT
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.
Comment 74 Frank Wein [:mcsmurf] 2013-09-16 11:17:22 PDT
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.
Comment 75 NoOp 2013-11-01 18:20:54 PDT
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'.

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