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)
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™ Plug-in::$ 1:application/x-java-applet:Java™ 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•12 years ago
|
||
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•12 years ago
|
||
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
Comment 5•12 years ago
|
||
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>
Updated•12 years ago
|
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.
Comment 7•12 years ago
|
||
Why is this in Blocklisting? Are you saying that the plugin is being blocked when it shouldn't be?
Comment 8•12 years ago
|
||
> 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•12 years ago
|
||
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•12 years ago
|
||
> 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.
Reporter | ||
Comment 11•12 years ago
|
||
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
Reporter | ||
Comment 12•12 years ago
|
||
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.
Reporter | ||
Comment 13•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
fwiw jre1.7.0_04 is LESS than jre1.7.0_2
Reporter | ||
Comment 17•12 years ago
|
||
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
Reporter | ||
Comment 18•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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
Comment 21•12 years ago
|
||
What does about:plugins see 1.7.0_04 as? (name, filename, version, description)
Comment 22•12 years ago
|
||
FWIW, I don't think this is an issue with the Add-ons Manager or Blocklist service.
Reporter | ||
Comment 23•12 years ago
|
||
@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•12 years ago
|
||
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
Comment 25•12 years ago
|
||
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•12 years ago
|
||
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."
Reporter | ||
Comment 27•12 years ago
|
||
@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
Reporter | ||
Comment 29•12 years ago
|
||
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
Comment 30•12 years ago
|
||
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
Reporter | ||
Comment 31•12 years ago
|
||
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.
Reporter | ||
Comment 32•12 years ago
|
||
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•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
(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•12 years ago
|
||
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™ Plug-in::$ 1:application/x-java-applet:Java™ Plug-in Applet::$ 2:application/x-java-applet;version=1.1:Java™ Plug-in::$ 3:application/x-java-applet;version=1.1.1:Java™ Plug-in::$ 4:application/x-java-applet;version=1.1.2:Java™ Plug-in::$ 5:application/x-java-applet;version=1.1.3:Java™ Plug-in::$ 6:application/x-java-applet;version=1.2:Java™ Plug-in::$ 7:application/x-java-applet;version=1.2.1:Java™ Plug-in::$ 8:application/x-java-applet;version=1.2.2:Java™ Plug-in::$ 9:application/x-java-applet;version=1.3:Java™ Plug-in::$ 10:application/x-java-applet;version=1.3.1:Java™ Plug-in::$ 11:application/x-java-applet;version=1.4:Java™ Plug-in::$ 12:application/x-java-applet;version=1.4.1:Java™ Plug-in::$ 13:application/x-java-applet;version=1.4.2:Java™ Plug-in::$ 14:application/x-java-applet;version=1.5:Java™ Plug-in::$ 15:application/x-java-applet;version=1.6:Java™ Plug-in::$ 16:application/x-java-applet;jpi-version=1.6.0_20:Java™ Plug-in::$ 17:application/x-java-bean:Java™ Plug-in JavaBeans::$ 18:application/x-java-bean;version=1.1:Java™ Plug-in::$ 19:application/x-java-bean;version=1.1.1:Java™ Plug-in::$ 20:application/x-java-bean;version=1.1.2:Java™ Plug-in::$ 21:application/x-java-bean;version=1.1.3:Java™ Plug-in::$ 22:application/x-java-bean;version=1.2:Java™ Plug-in::$ 23:application/x-java-bean;version=1.2.1:Java™ Plug-in::$ 24:application/x-java-bean;version=1.2.2:Java™ Plug-in::$ 25:application/x-java-bean;version=1.3:Java™ Plug-in::$ 26:application/x-java-bean;version=1.3.1:Java™ Plug-in::$ 27:application/x-java-bean;version=1.4:Java™ Plug-in::$ 28:application/x-java-bean;version=1.4.1:Java™ Plug-in::$ 29:application/x-java-bean;version=1.4.2:Java™ Plug-in::$ 30:application/x-java-bean;version=1.5:Java™ Plug-in::$ 31:application/x-java-bean;version=1.6:Java™ Plug-in::$ 32:application/x-java-bean;jpi-version=1.6.0_20:Java™ Plug-in::$ 33:application/x-java-vm-npruntime:::$ [INVALID]
Comment 37•12 years ago
|
||
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.
Reporter | ||
Comment 38•12 years ago
|
||
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 40•11 years ago
|
||
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.
Updated•11 years ago
|
Priority: -- → P5
Comment 41•11 years ago
|
||
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•11 years ago
|
||
Changing back the component per the latest comment.
Component: Plug-ins → Blocklisting
Product: Core → addons.mozilla.org
Comment 43•11 years ago
|
||
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]
Comment 44•11 years ago
|
||
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•11 years ago
|
||
(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•11 years ago
|
||
The block modifications are now staged. Please verify that they are working as expected.
Comment 47•11 years ago
|
||
(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•11 years ago
|
||
Did you see the plug-in on Firefox?
Comment 49•11 years ago
|
||
(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•11 years ago
|
||
(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)
Comment 51•11 years ago
|
||
> Philip, can you test this?
Unfortunately I can only test on Windows.
Flags: needinfo?(philip.chee)
Comment 52•11 years ago
|
||
The blocks were staged for all platforms. Some cursory testing on Windows should be sufficient to push these changes to production.
Comment 53•11 years ago
|
||
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•11 years ago
|
||
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.
Reporter | ||
Comment 55•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
> 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•11 years ago
|
||
(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•11 years ago
|
||
So I don't know what version of libstdc++.so is on our Linux boxes and whether it has the necessary symbols
Comment 60•11 years ago
|
||
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•11 years ago
|
||
(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•11 years ago
|
||
(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•11 years ago
|
||
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•11 years ago
|
||
(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.
Reporter | ||
Comment 65•11 years ago
|
||
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•11 years ago
|
||
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.
Reporter | ||
Comment 67•11 years ago
|
||
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
Comment 68•11 years ago
|
||
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.)
Updated•11 years ago
|
Whiteboard: [add "p119", "p132", and "p210" to blocklist] → [workaround: comment 68]
Updated•11 years ago
|
Component: Blocklisting → Build Config
Product: addons.mozilla.org → SeaMonkey
Version: unspecified → Trunk
Comment 69•11 years ago
|
||
jorgev, thanks so far! Callek, ewong, please take over.
Assignee: jorge → nobody
Comment 70•11 years ago
|
||
> 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•11 years ago
|
||
(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).
Reporter | ||
Comment 72•11 years ago
|
||
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•11 years ago
|
||
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
Comment 74•11 years ago
|
||
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
Reporter | ||
Comment 75•11 years ago
|
||
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'.
Updated•11 years ago
|
Status: NEW → UNCONFIRMED
Ever confirmed: false
Updated•11 years ago
|
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.
Description
•