JDK-4798569 : Mozilla can not display Java applet with relative "width" attribute correctly.
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.2.0,1.4.0,1.4.1_02
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,solaris_8,solaris_9
  • CPU: x86,sparc
  • Submitted: 2003-01-03
  • Updated: 2011-04-15
  • Resolved: 2004-11-26
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.
Other Other
1.4.1_05 05Fixed 1.4.2_02Fixed
Related Reports
Duplicate :  
JDK-4861821 - resize of browser window does not resize the applet
Duplicate :  
JDK-4818601 - Applets with a percentage width not render correctly an html table
Description
SunOS grandslam 5.8 Generic_108528-14 sun4u sparc SUNW,Sun-Fire-280R

Visit this page:
http://www.mozilla.org/quality/browser/front-end/testcases/oji/objecttest7.html
You can see the original applet and some applets with "width" attribute as
following:     
applet width=25%
applet width=15%
applet width=10%

They should be in defferent width, but now, they are all same and very thin.

But the applet with relative "height" attribute is OK.
http://www.mozilla.org/quality/browser/front-end/testcases/oji/objecttest4.html
###@###.### 10/27/04 08:00 GMT

Verified on JRE1.4.2_06-ea-b01
###@###.### 11/4/04 02:54 GMT
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_05 1.4.2_02 tiger FIXED IN: 1.4.1_05 1.4.2_02 tiger INTEGRATED IN: 1.4.1_05 1.4.2_02 tiger tiger-b14 VERIFIED IN: 1.4.1_05 1.4.2_02
14-06-2004
EVALUATION The testcase works on windows platform. in the testcase, the applet is inside one table. table's reflow process can be divided into two step, first, give unconstrained width and height to reflow childen, childen will calculate their own width and height, after it, table will balance column width, then do second reflow so to a applet inside one table, ObjectFrame::Reflow() will be called two times. I think this is a bug of unix JPI. assign to xiaobin. ###@###.### 2003-01-06 I don't think it is the JPI/JRE bug. The reason is simple. The same applet works fine if we remove the applet from the table. The applet also fails in Windows for Mozilla (if you reload the applet) if table is there. Basically we need to understand why adding the applet to the table makes such difference (it makes the width of applet become 0 so the applet fails to load, see JitterText.java in my directory). ###@###.### 2003-01-06 xiaobin, the testcase works fine in windows, even reload or shift-reload. so the problem only accurs on unix platform. I konw if I remove table tag outside the applet, the applet will show correctly. I have described table reflow process, it will do two step reflow. first with unconstrained size, then with a calculated size. during first reflow, (you can see the function of nsObjectFrame::Reflow()), GetDesiredSize(), it will set metrics.width as 0. then do second reflow, GetDesiredSize(), will set metrics.width as one calculated value, not 0. The problem is that unix JPI only use the first width value (the value is 0), regardedless the second value(not zero). windows JPI has no problem about this. ###@###.### 2003-01-07 It is not the problem of windows id as suggested by Joshua. You can print out the value of the windows id to verify this. It is again the problem of whether the passed in width is 0 or not. As Jerry mentioned the reflow process of Mozilla layout engine, the browser calls MNetscapePluginObject:SetWindow couple times and the initial width are 0, and the last one is the real width. Certainly JPI can hack to ignore the zero width, however, this is far way to close the right solution. Browser should make sure whatever passed in width to the Java is correct since browser knows what itself is doing. For JPI in windows, if we print out the width value in WNetscapePluginObject:setWindow, you can see the value will be always 0, and setWindow is actually called four times. This is wrong (at least not consistent to the Unix case). However, the reason of why Window can display the applet is because the applet code gets the right width when it calls createImage. However, in Unix it is not the case. This is all handled by java awt. In all, there are at least two problems here as I see: * OJI module should make sure setWindow is called consistently cross different platforms (Unix and Windows). * If Mozilla layout engine needs to do reflow or whatever, the request for drawing the applet should meet the precondition. The width and height should be a valid value instead of faked. ###@###.### 2003-01-07 I insert "System.out.println("width = " + width)" into mantis/deploy/src/plugin/src/share/classes/sun/plugin/viewer/MNetscapePluginObject.java in the method "setWindow", before "if (winID == newID) return", when we load the testcase, the following message display in Java Console Window: width = 0 width = 0 width = 0 width = 0 width = 400 width = 400 width = 0 width = 0 java.lang.IllegalArgumentException: Width (0) and height (80) cannot be <= 0 at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:999) at sun.awt.motif.MComponentPeer.createImage(MComponentPeer.java:470) at java.awt.Component.createImage(Component.java:2655) at JitterText.init(JitterText.java:64) at sun.applet.AppletPanel.run(AppletPanel.java:352) at java.lang.Thread.run(Thread.java:536) width = 0 width = 0 width = 0 width = 0 width = 400 width = 193 width = 116 java.lang.IllegalArgumentException: Width (0) and height (80) cannot be <= 0 at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:999) at sun.awt.motif.MComponentPeer.createImage(MComponentPeer.java:470) at java.awt.Component.createImage(Component.java:2655) at JitterText.init(JitterText.java:64) at sun.applet.AppletPanel.run(AppletPanel.java:352) at java.lang.Thread.run(Thread.java:536) width = 77 width = 400 width = 190 width = 114 width = 76 So we can conclude that JPI block the right width set into JVM side. it only pass the first value which is zero. ###@###.### 2003-01-09 please pay attention that setWindow should not only set native window ID but also resize. ###@###.### 2003-01-09 SetWindow will be called when browser resize, however, the applet width will be the same. Anyway, I guess it will be easy in JPI side to make the change. Just check whether the width/height is zero or not, if either one of them is zero, setWindow will return without doing anything. ###@###.### 2003-01-09 After talking to browser engineer in China (Joshua Xia), I think we should reconsider the fix and target to Tiger release. Joshua also has some other bugs assigned. Basically we have two problems : * Whether it is legal to call SetWindow with 0 width and 0 height * Whether it is okay to return without doing anything if passed in window id hasn't been changed. We need to consider both assumptions in Tiger OJI redesign. ###@###.### 2003-01-17 Since AWT does not allow width/height to be 0, we will add this restriction to JPI code to filter that. ###@###.### 2003-04-07 We should get this approved since this bug prevents the user from displaying applet with relative width and height correctly.
07-04-2003
SUGGESTED FIX This is a JPI 's bug. I remember that there is a duplication of this bug in bugtraq that I assigned to JPI group but has been assigned back. Please read source code: mantis/deploy/src/plugin/src/share/classes/sun/plugin/viewer/MNetscapePluginObject.java on line 247, in the method "setWindow", "if (winID == newID) return" block all new size be set into JVM/JPI side from Browser side if there is no new window ID from browser side. So the size of Applet will never dynamically changed according to html page 's size after it is loaded. for example, try the simplest testcase: <html> <applet code="foo.class" height=100%, width=100%> </html> the size of this applet is ok when it is loaded, but when the size of browser change, the size of the applet don't change because window ID is unchanged. if you reload this page, the size of the applet change because new window ID is created. Suggested fix: JPI side must resize applet even though there is no new window ID created. ###@###.### 2003-01-07
07-01-2003