JDK-4136103 : JApplet repaint/deadlock problems
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.0.2,1.1.2,1.2.0
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS:
    solaris_2.5.1,solaris_2.6,windows_nt solaris_2.5.1,solaris_2.6,windows_nt
  • CPU: unknown,x86,sparc
  • Submitted: 1998-05-07
  • Updated: 1999-01-15
  • Resolved: 1999-01-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.2.0 1.2beta4Fixed
Related Reports
Duplicate :  
JDK-4122792 - Applet stops repainting using swing components
Duplicate :  
JDK-4136637 - SwingUtilities.invokeLater fails when used with a JApplet
Duplicate :  
JDK-4135781 - Jmenu(Bar) hangs in JFrame of applet when leaving page
Duplicate :  
JDK-4134900 - PLUGIN Activator 1.1 DOES NOT WORK WITH JTextField
Description
When opening a modal dialog from an Applet running in Java Plug-in 1.1, the dialog is never repainted when you type in textfields unless you force the repaint by overlapping or resizing the dialog.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2beta4 1.2fcs FIXED IN: 1.2beta4 INTEGRATED IN: 1.2beta4 1.2fcs
14-06-2004
EVALUATION hans.muller@Eng 1998-05-07 Hypothesis: the problem is that the modal dialog event dispatching thread isn't recognized by SystemEventQueueUtilities. This is consistent with RunnableCanvas.lookup() always failing (we've verified that it does in this case). The fix [thanks to Jeff] may be to use one RunnableCanvas per top level modal Dialog and JApplet, instead of just JApplets. jeff.dinkins@Eng 1998-06-01 The above works. hans.muller@Eng 1998-06-02 In addition to the strategy outlined above, There were many changes to get this working. In SystemEventQueueUtilities.java: - Defined ComponentWorkRequest.run() to do the RepaintManager work and clear the isPending flag. Added queueComponentWorkRequest(), which the RepaintManager uses, which ensures that there's only zero or one ComponentWorkRequest runnables queued per root Window or Applet. - To allow for Component trees that don't have a RootPaneContainer, e.g. an applet java.awt.Frame popup, we keep a table that maps from "roots" (a root is an Applet or a Window) to the current ComponentWorkRequest. - To prevent a popup from clobbering the mapping from an event dispatching thread (or thread group) to an applets RunnableCanvas: don't overwrite an existing mapping in the RunnableCanvas constructor. - In RunnableCanvas.lookup(), use ComponentWorkRequest.component first, then fallback to thread or thread group. In SwingUtilities.java: Fixed getRootPane(): now works correctly if its argument is a JRootPane or a RootPaneContainer. Added getRoot() which finds the first Window or (last) Applet ancestor for a component. In RepaintManager.java: - In addDirtyRegion(): ignore null components, components with no peer, and components with width, height <= 0, components with no root. Now uses SystemEventQueueUtilities.queueComponentWorkRequest(). - In addInvalidComponent(): ignore null components, components with no peer, components with no root, components with no validateRoot. Now uses SystemEventQueueUtilities.queueComponentWorkRequest().
11-06-2004