United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4798569 Mozilla can not display Java applet with relative "width" attribute correctly.
JDK-4798569 : Mozilla can not display Java applet with relative "width" attribute correctly.

Details
Type:
Bug
Submit Date:
2003-01-03
Status:
Closed
Updated Date:
2011-04-15
Project Name:
JDK
Resolved Date:
2004-11-26
Component:
deploy
OS:
solaris_9,solaris_8,linux
Sub-Component:
plugin
CPU:
x86,sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.2.0,1.4.0,1.4.1_02
Fixed Versions:
1.4.1_05 (05)

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:

Sub Tasks

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
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
                                     
2003-01-07
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.
                                     
2003-04-07
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


                                     
2004-06-14



Hardware and Software, Engineered to Work Together