JDK-4668508 : Copying from JTextComponent break pasting from system clipboard.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-04-15
  • Updated: 2003-04-12
  • Resolved: 2002-08-08
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.4.2 mantisFixed
Related Reports
Duplicate :  
JDK-4648521 - Copy/Paste stops working after opening modal dialog
Relates :  
JDK-4692059 - Reg-test LostOwnershipChainTest/SystemClipboard2ProcTest.html failing
Description

Name: gm110360			Date: 04/15/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Windows 95, 98, NT, 2000, XP

EXTRA RELEVANT SYSTEM CONFIGURATION :
Internet Explorer 4.0 and later
All version of netscape
Also occures with previous version of the JRE and plug-in

A DESCRIPTION OF THE PROBLEM :
If copying text from a JTextComponent inside an applet, the
applet will always paste the last copied text after
reloading the applet even if the system clipboard contains
other string data.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Make sure the applet has access to the system clipboard,
either by signing it or modifying your local java.policy
file with permission
java.awt.AWTPermission "accessClipboard";
2. Start the applet
3. Copy some text from outside the applet (notepad)
4. Paste it into the JTextPane
5. Copy some text inside the applet
6. Leave the applet
7. Copy some other text from an external application
8. Start the applet again in the same internet explorer
window
9. Paste the text from the clipboard.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected result is the contents of the system clipboard.
Actual result is the last copied text from the applet.
Futhermore, no pasting from another datasource is possible.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class test_applet extends javax.swing.JApplet {
	private javax.swing.JTextPane pane;

	public void init() {
		pane = new javax.swing.JTextPane();
		
		getContentPane().add(pane);
	}
}

HTML file

<HTML>
<BODY>
<applet code = test_applet width=250 height=250>  
</applet> 
</BODY>
</HTML>

---------- END SOURCE ----------
(Review ID: 145234) 
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis mantis-b02 FIXED IN: mantis mantis-b02 INTEGRATED IN: mantis mantis-b02 VERIFIED IN: mantis
17-09-2004
PUBLIC COMMENTS .
17-09-2004
SUGGESTED FIX Name: dsR10078 Date: 05/21/2002 Use PropertyChangeSupport to track the changes of "disposed" property of an AppContext. Register all instances of SunClipboard as PropertyChangeListeners to receive notifications of the changes. Whenever an AppContext associated with the clipboard contents is disposed, the references to the current contents and owner are cleared and then ClipboardOwner.lostOwnership is called on the event dispatch thread of an AppContext being destroyed. The AppContext disposal implementation guarantees that ClipboardOwner.lostOwnership will be called before the event dispatch thread is stopped. In native Solaris/Linux code we should additionally cleanup the global references related to the current clipboard contents. It isn't needed on Windows, since when the system clipboard contents is set we retrieve the data in all available formats and store it in the Windows system clipboard and so we don't need any references to the contents. ###@###.### 2002-05-20 ====================================================================== Name: dsR10078 Date: 05/29/2002 The fix also introduces three changes in the system clipboard behavior: 1.When the Java application owns the system clipboard and some other client acquires the clipboard ownership, the references to the current clipboard contents and owner are cleared immediatelly and then ClipboardOwner.lostOwnership is invoked on the event dispatch thread of owner's AppContext. The current implementation is to clear the references on the event dispatch thread just before lostOwnership is called. 2.When the system clipboard (or system selection) contents is set from an Applet and then the Applet is reloaded, that contents is no longer available in Solaris/Linux implementation and the selection ownership is lost. The cause is that on Solaris/Linux there is no global storage associated with the system clipboard and so whenever the system clipboard contents is requested this request is forwarded to the current clipboard owner. Eventually, it would lead to getTransferData() call on the Transferable that represents the contents, however in this scenario the Transferable belongs to the destroyed AppContext and so we cannot call any method on it. With the current implementation the system clipboard contents set before applet reload is available only within the same JVM. Any attempt to request the contents from another client fails. However, when the clipboard contents is requested within the same JVM, getTransferData() on the Transferable that represents the contents set before applet reload is called on the event dispatch thread of the new applet which is a security hole. 3.When null contents is passed to setContents() of the system Clipboard NullPointerException is thrown without any modifications to the Clipboard. The current implementation updates Clipboard references to the contents and owner and then throws the exception. This leaves the Clipboard in an inconsistent state, since the reference to the contents context is not updated and the clipboard contents is not updated on the native level. ###@###.### 2002-05-29 ======================================================================
29-05-2002
EVALUATION Reporter, can you reprocue this bug using appletviewer? If yes, please reassign this to swing group. ###@###.### 2002-04-19 Since I can reproduce this bug using appletviewer. I am reassigning this bug to Swing component. ###@###.### 2002-04-22 I have determined that the Swing application is always using the System clipboard returned from Toolkit.getClipboard(). It seems that when the user leaves the applet page and then returns, they temporarily get a clipboard that is disconnected from the actual system clipboard. However, the next copy from a native application while the applet is visible seems to sync them up. I'm not sure if this is a plugin issue or an AWT issue. Re-assigning to AWT to investigate. ###@###.### 2002-04-23 Reassigning to Drag&Drop. ###@###.### 2002-04-23 Name: dsR10078 Date: 05/21/2002 See comments. ###@###.### 2002-05-20 ======================================================================
23-04-2002