JDK-6801859 : size of temp file .emf is many times larger in JDK6 and NOT deleted after printing applet using IE
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u5
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows
  • CPU: x86
  • Submitted: 2009-02-05
  • Updated: 2010-04-07
  • Resolved: 2009-02-06
Related Reports
Relates :  
JDK-6804454 - RFE: Provide a way to control the printing dpi resolution from MSIE browser print. See also 6801859
Description
JDK 6 upd 5, 7, 10 that have been tried and reproduced the
issue.
Windows XP
Microsoft I.E. 6 and 7.


Steps to reproduce:

Internet Explorer 6.0.2900.2180.xpsp_sp2.080814-1233 in both
cases.

Loaded the demo applet from Sun's own site
http://java.sun.com/applets/jdk/1.4/demo/applets/SpreadSheet/example1.ht
ml

The applet displayed the 4 x 3 spreadsheet.  The applet image is
relatively small.  I highlighted cell C4, then requested File->Print
from the Browser.

With JRE 1.4.2_10 the .emf file produced is 154,068 bytes.  The file is
named:
/cores/JRE142_10.AL7EX49K.emf

With JRE 1.6.0_05 the .emf file produced is 1,843,724 bytes.  The file
is named:
/cores/JRE160_05.OLOJU5K3.emf


You may want to add this in comments section for internal
view only.
======================================

Customer description of the problem.

When MS Internet Explorer (v 6.0.2900.2180.xpsp_sp2_gdr.080814-1233) browser-ini
tiate print command is used to print a page displaying a Java applet [seen with
SRE 1.6.0_05 and 1.6.0_07] the applet's image is saved to an .emf file (enhanced
windows metafile). This file is not deleted even after MSIE is exited and will
\ persist in the %TEMP% directory indefinitely. The file cannot be deleted as l
ong as MSIE is running. Because the file size is much larger with Java 1.6.0 th
an with Java 1.4.2, the user's drive can fill up with these files and result in
other errors from lack of space.

Have test results from 2006 with Windows XP SP1 that in that release (and JRE 1.
4.2_04) the .emf file was deleted as soon as the printer successfully acknowledg
ed completion of the print job. (Do not currently have configuration to reprodu
ce this test.)


Do not see emf files created when using Firefox 3.0 to print pages with applets.
However, Firefox print preview shows a blank space instead of the applet's dis
played image; the print output on paper is correct however.

This behavior does not produce any errors until the policy quota for temp files
is reached or the disk drive is filled. This can happen if the user keeps MSIE
up for a long time and prints many pages with applets. This is much more seriou
s with JRE 1.6.0 than 1.4.2 as the metafiles are typically ten times larger with
1.6.0 than for the same applet running under 1.4.2.

Additional technical information from customer
------------------------------------------------------

1. I have tested only Firefox 3.0 with JRE 1.6.0_07 on Windows XP.  I
have not found out about the mechanism Mozilla Firefox uses to print
objects embedded on web pages.  It does not appear to use .emf files,
even in the Windows implementation.  In my testing, the applet displayed
only on the printout; it was blank space in the print preview dialog.


2.  The vendor that is customizing the browser has told us so far that
they let the native MSIE print engine operate on the web pages.  The
link between MSIE browser print and the overridden PrintAll method in
our applet would be through the Java plug-in.


3. Native MSIE uses the .emf file to marshal to the printer, the
rendered image from embedded objects (such as Java applets) that the
browser does not render via its own code.  I have reached out to our
technical contact at Microsoft for a clearer understanding, as well as
answer the question you posed in a later e-mail
Comments
EVALUATION Adding clarification to that last comment : "old" plugin - ie the only one in all releases prior to JDk 6 update 10, Plugin did create an EMF, but it so happens that IE *also* uses an EMF, so -> User selects Browser: File->Print -> IE obtains a printer DC (hdc1) to render its own content -> For each "3rd party plugin content" on the page (eg Flash, Java), IE creates a *disk* meta file (mf1) and passes a DC (hdc2) for it to the plugin. -> In the case of Java Plugin, it creates a *memory* metafile (mf2), creates a DC for that (hdc3) and asks the JRE to render the applet content into hdc3 which corresponds that metafile (mf2) After completion Plugin plays the contents back into hdc2, then deletes the memory metafile (mf2). -> IE then plays back the contents of mf1 into hdc1, but *fails* to then delete the disk metafile mf1 -> Printing is complete. So it is something of a coincidence that two metafiles are involved, but the one that is leaked is not created by any part of plugin, so this is purely a Microsoft IE issue. Those of is who experienced this were all using IE 7 but without further testing we can't say if its unique to that browser version, or if IE6 or even IE8 are similarly afflicted. "new plugin" can't help, since although it eliminates the internal use of a metafile that is not the source of the problem.
06-02-2009
EVALUATION For the new java plugin for IE, we don't create an emf file explicitly. In the OnDraw method, we received a hdcDraw inside the ATL_DRAWINFO structure from the browser. The hdcDraw is of OBJ_ENHMETADC type. Regarding the .emf files remain in the "temp" directory after printing, this is a known issue related to printing embedded controls inside a web page as described in the following: http://www.canoneasywebprint.com/en/Faqs.html#sec7_otherissues http://bugs.adobe.com/jira/browse/FP-112
06-02-2009
EVALUATION CU provided related source code for the printing operation /net/cores.central/cores/66180663/PrintAll/PrintALl.java The EMFFiles are in /net/cores.central/cores/66180663/EMFFiles -rw-rw-rw- 1 nobody nobody 154068 Feb 5 11:43 JRE142_10.AL7EX49K.emf -rw-rw-rw- 1 nobody nobody 1843724 Feb 5 11:44 JRE160_05.OLOJU5K3.emf
05-02-2009
EVALUATION The larger file is because of the fix 4970557 : Browser printing of applets is at screen resolution on windows. This is necessary to improve printing quality and was implemented for 1.5 way back in 2003. So that is functioning as designed. The "leak" of temp files isn't something that the 2D printing code is responsible for. We are handed a Windows DC for a metafile that was created by the Java plugin code in deploy/src/plugin/win32/nscore/CJavaPlugin.cpp Here's the essence of that code, minus some error handling : HDC hPluginDC = CreateEnhMetaFile(hDC, NULL, NULL, NULL); m_pPluginObject->print(hPluginDC); HENHMETAFILE hMF = ::CloseEnhMetaFile(hPluginDC); ::PlayEnhMetaFile(hDC, hMF, &rect); ::DeleteEnhMetaFile(hMF); ======== As you can see this doesn't explicitly create a temporary file, that is done by windows and at the end of printing DeleteEnhMetaFile() is called. The MSDN docs state the following : ===== DeleteEnhMetaFile Function http://msdn.microsoft.com/en-us/library/dd183534(VS.85).aspx ... If the hemf parameter identifies an enhanced metafile stored in memory, the DeleteEnhMetaFile function deletes the metafile. If hemf identifies a metafile stored on a disk, the function deletes the metafile handle but does not destroy the actual metafile. ---- CreateEnhMetaFile Function http://msdn.microsoft.com/en-us/library/dd183498(VS.85).aspx lpFilename [in] Pointer to the file name for the enhanced metafile to be created. If this parameter is NULL, the enhanced metafile is memory based and its contents are lost when it is deleted by using the DeleteEnhMetaFile function. -------- ========== So since plugin creates it as a MEMORY DC (see the null parameters to CreateEnhMetaFile) and properly calls DeleteEnhMetaFile() it appears to be up to windows to clean up this file. The docs even lead one to believe that a file isn't used in this cases. Likely windows does in fact, and has not yet closed the file. This appears to be a windows bug, since the implementation isn't performing as per spec. It is likely possible to work around this by using the printer DC directly. BTW This is seen only in IE since the firefox plugin code doesn't use a metafile.
05-02-2009