Description of problem: One of the websites we rely on is currently unusable because of a Java applet on its search page. Once this applet loads, Firefox becomes unusable (see below) and must be killed from a terminal. Version-Release number of selected component (if applicable): java-1.6.0-openjdk-plugin-1.6.0.0-7.b12.fc10.x86_64 firefox-3.0.5-1.fc10.x86_64 How reproducible: Always. Steps to Reproduce: 1. Go to http://zinc.docking.org/choose.shtml 2. Type in 'foo' in the 'ZINC codes (1 per line)' box. 3. Click on the 'QUERY DATABASE' button. Actual results: Clicking on the link gives the GNOME 'hourglass' cursor, but it never loads. Furthermore, after this point keyboard entry is broken; for example, if you try to type into the location bar, characters show up in the reverse order (i.e. from right to left, so typing 'foobar' gives 'raboof'), and the delete and cursor keys do nothing. The Firefox window will disappear if the mouse is used to close it, but the 'firefox' process continues to run, and must be killed from a terminal. Expected results: A ZINC search results page (probably garbage though, since we put in a garbage query). Also, we should be able to continue using Firefox to visit other web sites. Additional info: If Java is disabled in Firefox preferences, the website works normally. (Unfortunately, however, the Java applet is needed to construct searches, so this is not a great solution for us.) Our users also report that this website used to work in Fedora 9. I ran firefox with "ICEDTEAPLUGIN_DEBUG=true firefox" and will attach the /tmp/java.* files and the standard output from the firefox process.
Created attachment 328026 [details] /tmp/java.stderr.gz
Created attachment 328027 [details] /tmp/java.stdout
Created attachment 328028 [details] debug-out.gz
This still occurs with the latest Firefox update. Is there anything else you'd like us to run at this end to clarify the problem?
Appears to work now with: java-1.6.0-openjdk-plugin-1.6.0.0-7.b12.fc10.x86_64 firefox-3.0.5-1.fc10.x86_64 I guess it has been coincidentally fixed upstream, since I've seen no movement on this bug here.
Actually, it was reproducible and subsequently fixed upstream. Just forgot to update this bug :/ ... Since you have verified that the fix works, I am just going to go ahead and close this!