JDK-6673601 : Applet must obey either boxbgcolor or page background color before loading
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-03-11
  • Updated: 2010-09-08
  • Resolved: 2008-06-18
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.
6u10 b26Fixed
Related Reports
Relates :  
Relates :  
Relates :  
In the period before an applet starts loading, the current (both old and new) Java Plug-Ins do not paint the region associated with the applet, which tends to cause it to show up white at least on Windows. If the HTML developer has selected a different background color for the web page, this means that there will be a white flicker in the applet's area that the applet developer has no control over and which looks extremely unprofessional especially compared to the competition. We need to do something about this. The initial thinking is to pay attention to the boxbgcolor if specified, and if not, to use the browser's scripting engine to figure out the page's background color, and to use the native OS's drawing primitives to paint the applet's region before the client JVM starts executing the applet content.
See the following forum thread for another possible test case for this issue:


post by "davester", with test case hosted at http://cardmeeting.com/ ... .

EVALUATION Two issues here: 1. In IE, the plugin control window does not set the background color when paint and erase background. We need use the background color specified in <applet> parameter "boxgbcolor" to paint the control window. This does not affect FF3 2. Plugin Embedded frame is constructed to disable erasing background. However, its superclass W/XEmbeddedFrame calls show() in their constructors. This causes the embedded frame's background erased before the GrayBox Panel starts to render the animation gif.