RESOLVED FIXED107501
REGRESSION (r131539): Java applet is not started after changing visibility from none to block
https://bugs.webkit.org/show_bug.cgi?id=107501
Summary REGRESSION (r131539): Java applet is not started after changing visibility fr...
Andrew Herron
Reported 2013-01-21 21:42:26 PST
Java Applets have a defined lifecycle (init, start, stop, destroy). Depending on the browser, when an applet is hidden may be told to stop; in that case when it is shown again it is supposed to be told to start again. This is documented in a Java tutorial: http://docs.oracle.com/javase/tutorial/deployment/applet/lifeCycle.html A recent change in Webkit has broken the management of this lifecycle. Steps to Reproduce: Extract the attached appletlifecycle.zip 1) Compile the applet using IntelliJ or by executing buildClasses.sh 2) Load test.html 3) Click on the "replicate" button Expected Results: Applet should hide, then half a second later re-appear with the "applet is running" message Actual Results: The div re-appears, but the applet inside it does not. If you open the Java console, the applet prints lifecycle messages - it will display init, start, stop and destroy but never start again. Replicated in Webkit build r140374, as well as Chrome 24 on Linux, Windows and OS X (after restoring Java 6 as the active Java plugin). Using Safari 6.0.2, FireFox or IE (on appropriate platforms) the applet re-appears with the running message and the start message appears in the Java console. Note that some browsers don't stop the applet when hidden, and others (eg Safari/Webkit on OS X) require the test page to be run from a web server instead of locally. Replicated with Java 1.6.0_38 and Java 1.7.0_11. Regression: We're not sure exactly when the regression occurred; we first observed this around the time that Chrome 24 was promoted to the stable channel.
Attachments
complete replication case (5.18 KB, application/zip)
2013-01-21 21:42 PST, Andrew Herron
no flags
Andrew Herron
Comment 1 2013-01-21 21:42:48 PST
Created attachment 183886 [details] complete replication case
Alexey Proskuryakov
Comment 2 2013-01-25 11:04:25 PST
Regressed in <http://trac.webkit.org/changeset/131539>. Julien, Eric, can you look into this?
Alexey Proskuryakov
Comment 3 2013-01-25 11:04:41 PST
Julien Chaffraix
Comment 4 2013-02-11 13:16:49 PST
Reverted the incriminated changeset in http://trac.webkit.org/changeset/142500. I haven't been able to reproduce this bug but it should be fixed.
Andrew Herron
Comment 5 2013-02-12 14:15:43 PST
Confirmed in build r142638. Thanks!
Note You need to log in before you can comment on or make changes to this bug.