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.

EVALUATION
The recursive action looks like that:
WDataTransfer::translateTransferable(...) { +HTML header for CF_HTML native format }
--(super with HTMLFlavor)-->DataTransfer::translateTransferable()
--(if flavor.isRepresentationClassInputStream() call translateTransferable again with
plainTextFlavor)-->WDataTransfer::translateTransferable(...){ +second HTML header for CF_HTML native format - that is a problem!}
--(super with plainTextFlavor)-->DataTransfer::translateTransferable()
Using of recursion has no reason at that place because it needs just for particular InputStream to byte[] conversion. Now it is realized as separate translateTransferableString function.
The same problem was in the translateBytesOrStream function that is using at clipboard data extraction. It does not produce an error yet, but gets lack in performance and creates a big risk for any platform-dependent modification.
HTML format is the only format with custom platform action at translateTransferable stage:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
public byte[] translateTransferable(Transferable contents,
DataFlavor flavor,
long format) throws IOException
{
byte[] bytes = super.translateTransferable(contents, flavor, format);
if (format == CF_HTML) {
bytes = HTMLSupport.convertToHTMLFormat(bytes);
}
return bytes;
}
The clipboard data exchange in JAVA is different for in-process and out-process communications. We most of clipboard support subroutines executing entirely just in case of out-process interaction. That is why HTMLTransferTest.java need to run child process. System.err was chosen by historical reason: ImageTransferTest is a direct child of ImageTransferTest.
DnDHTMLToOutlookTest is valid for X too. Word and Outlook mentioned as optional program. Any HTML document editor are acceptable at any platform. But MS Outlook and Word for Window platform would provide more extended coverage for test in future, when HTML clipboard format ver 1.0 will accepted for review.
The tests were designed with aim to cover backward compatibility and compatibility with native applications while changing HTML clipboard format.

2006-12-25

EVALUATION
The main problem is in recursion call of public virtual function
public byte[] translateTransferable(Transferable contents,
DataFlavor flavor,
long format) throws IOException
in
src\share\classes\sun\awt\datatransfer\DataTransferer.java
that is reimplemeted in
src\windows\classes\sun\awt\windows\WDataTransferer.java
That leads to doubled HTML format-head concatination with clipboard data stream.
This practice does not correspond to good software design and have to be rewritten. But "two-bytes fix" is availuable for service packs (look to the "Suggested fix").
Correct fix includes translateBytesOrStream and translateTransferable functions rewriting to avoid the recursion.
A number of tests have to be implemented to test backward compartibility as well as interaction with native applications in clipboard and DnD operations.
HTML text transport have to be upgraded, but this is a subject for another task.