|
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.
xxxxx@xxxxx 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).
xxxxx@xxxxx 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.
xxxxx@xxxxx 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.
xxxxx@xxxxx 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.
xxxxx@xxxxx 2003-01-09
please pay attention that setWindow should not only set native window ID but also resize.
xxxxx@xxxxx 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.
xxxxx@xxxxx 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.
xxxxx@xxxxx 2003-01-17
Since AWT does not allow width/height to be 0, we will add this restriction to JPI code to filter that.
xxxxx@xxxxx 2003-04-07
We should get this approved since this bug prevents the user from displaying applet with relative width and height correctly.
|
