United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6673601 Applet must obey either boxbgcolor or page background color before loading
JDK-6673601 : Applet must obey either boxbgcolor or page background color before loading

Details
Type:
Bug
Submit Date:
2008-03-11
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-06-18
Component:
deploy
OS:
generic
Sub-Component:
plugin
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b26)

Related Reports
Relates:
Relates:
Relates:

Sub Tasks

Description
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:

http://forums.java.net/jive/thread.jspa?threadID=38310&tstart=0

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

                                    

Comments
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.
                                     
2008-05-27



Hardware and Software, Engineered to Work Together