[Webkit-unassigned] [Bug 107501] New: Java applet lifecycle is not managed correctly

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=107501

           Summary: Java applet lifecycle is not managed correctly
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Critical
          Priority: P1
         Component: Java
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: andrew.herron at ephox.com


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.