United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4668508 Copying from JTextComponent break pasting from system clipboard.
JDK-4668508 : Copying from JTextComponent break pasting from system clipboard.

Details
Type:
Bug
Submit Date:
2002-04-15
Status:
Closed
Updated Date:
2003-04-12
Project Name:
JDK
Resolved Date:
2002-08-08
Component:
client-libs
OS:
windows_2000
Sub-Component:
java.awt
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.2 (mantis)

Related Reports
Duplicate:
Relates:

Sub Tasks

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
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
======================================================================
                                     
2002-04-23
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

======================================================================
                                     
2002-05-29
PUBLIC COMMENTS

.
                                     
2004-09-17
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


                                     
2004-09-17



Hardware and Software, Engineered to Work Together