Created attachment 580470 [details] Error log from Firefox 11.0 Description of problem: icedtea-web plugin is unable to load Geogebra applets both in Firefox and Chrome. Browsers won't crash but won't load the applet. Some applets get to the Geogebra loading screen, but the activity isn't loaded. Applets from http://java.sun.com/applets/jdk/1.4/index.html work just fine, so I think it's a Geogebra related bug only. Version-Release number of selected component (if applicable): icedtea-web-1.2-1.fc16.x86_64 java-1.6.0-openjdk-1.6.0.0-65.1.11.1.fc16.x86_64 Steps to Reproduce: 1. Go to http://recursostic.educacion.es/gauss/web/materiales_didacticos/primaria/actividades/novedades.htm 2. Click on any of the activities listed Actual results: Applet won't load. I've attached the error log I get when running from console. The first error message is shown when the applet won't load at all. The second one is shown when you get to the Geogebra loading screen, but the activity couldn't be loaded. Expected results: An interactive Geogebra activity is loaded. Additional info: I've downloaded the *.jar and *.ggb (Geogebra) files from the site and they run without any errors when executing from console: $ java -jar geogebra.jar activity.ggb This doesn't occur in Ubuntu 10.04 with openjdk and icedtea-web. The same bug can be reproduced in other sites, such as http://www.mathcasts.org/mtwiki/Construct/CompassStraightedge .
Jiri, can you please take a look? Thanks.
Quite interesting and tricky seams this one to me. The exception described above, is caused by loading (and using methods from) another jar, downloaded by not standard way (probably by url.getInputStream and in addition used in some creepy internal classloader) Few more facts: * both urls from reporter are pointing to same GeoGebra applets * GeoGebra applets are signed by globally trusted certificate (and doing such a nasty thing!) * runnig from comamndline (java -jar...) is not significant as there is no security manager during such a run * the behavior is same when run from javaws (with jnlp file created from html appelt tag) with the only "small" difference - the exception is consumed (probably in awt event queue thread) and so unrelated deadlock is detected much later I have suggested patch which is printing by above required debug outputs to upstream - http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-April/018330.html * I do not understand why issue is not replica-able on ubuntu. My first idea was that they are using different globally trusted keystores, but it is probably not true. My second idea is that there is still icedtea-web 1.0 (or 1.1?) which had (IIRC) not so strict classloader
* The fact that the some of applets are able to show splash screen, depends on calling methods from this "downloaded" jar. If those methods are called in init() then no splash is shown.If later, then at least splash screen is hown before cruel death
Created attachment 580746 [details] binary-blob reproducer geodebra.html is original reproducer geodebra.jnlp is the same, except rewritten to jnlp to be more easily debugged geodebra2.{jnlp,html} is "correct" way how to download resources. However does not help here, because it is using some really crazy internal classloader which is ignoring "external" (understand normal please) classpath.
I think i can easily make reproducer for icedte-web reproducers framework for geodebra.html/jnlp. To reproduce geodebra2.html/jnlp behavior can be more complicated (and if I'm right about the suspicions for crazy internal classlaoder - then even incorrect).
If we would like to fix the original issue (although I do not want to - i consider this very VERY nasty and do not wan to support this) and we maybe must to as proprietary plugin probably handle this "correctly", then my suggestion is this: in http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120427/da938d44/debuggingEnchancements.diff i have suggested to add debug line "Error! No security instance for signed "+source.toString()+" This source was loaded outside of netx, and application will have troubles to continue". So instead of this debugline, my fix would like to locate requested url/jar and regain signatures, and provide those just retrieved (and to cache them as it is done for normal resources during preloading) instead of returning null.
Reproducer for this issue with source codes for icedtea-web testsuite posted to review. http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-May/018357.html
fix posted to upstream review
fix posted to upstream review http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-May/018372.html
Fixed upstream. http://icedtea.classpath.org/hg/icedtea-web/rev/1d7e18be89f4 One more patch for this (and similar) issues is on the way, but appelts are working.
What release is this fix contained in for Fedora?
Currently it is in head, so it will reflect in 1.3, which is going to be in f18. I will try to negotiate backport to 1.2 so it will reach updates in f16+f17. after few iterations in head. Are you ok with it? Is it worthy? ( O:) )
Yes please for 1.2
backported to 1.2