Closed Bug 188454 Opened 19 years ago Closed 18 years ago

Mozilla can not display Java applet with relative "width" attribute correctly when the applet is inside table


(Core Graveyard :: Java: OJI, defect)

Not set


(Not tracked)



(Reporter: jerry.tan, Assigned: yuanyi21)




(Whiteboard: fixed_in_tiger)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212

Visit this page:
You can see the original applet and some applets with "width" attribute as
applet width=25%
applet width=15%
applet width=10%

They should be in defferent width, but not in unix platform.

Reproducible: Always

Steps to Reproduce:

I know there may have some bug like this has been fired on bugzilla,
lets discuss the issue here, and mark others as dup of this one.
*** Bug 119185 has been marked as a duplicate of this bug. ***
There are some basic info about this bug.
first,it only happens on unix platform, not windows platform,
second, if the applet with % width is not inside table, it will show correctly.

In the testcase, the applet is inside one table.
table's reflow process can be divided into two step,
first, give unconstrained width reflow childen,
  childen will calculate their own width and height,
after it, table will balance column width, then do second reflow.
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 in this case, nsObjectFrame::Reflow will be called multiple
times, and UNIX JPI function will be called multiple times,
it only set the applet's width as  the value of first reflow process, which is 0.

on JPI side, the resize function should be added into setWindow method,
on browser side, we should investigate width=0 is valid or invalid. or should
browser filter width=0.

html 4.0:
according to awt 's requirement, JPI will filter width = 0.
I'm having the same bug, ie. mozilla freezes when I set relative width to an 
applet inside a table. I'm on win2k, so unix is not the only platform where 
this bug occurs. I'm using :

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212

For my case I was able to create a workaround by setting the width onload by 
javascript. I will give you a snippet, maybe it can help some others :

<body onload="appletwidth()">

function appletwidth () {
	document.getElementById("applet").width = document.getElementById
("td").offsetWidth - 416


<td id="td"><img src="/img/menu/nav.gif" height=15 width=416 border=0 vspace=0 
	code="somecodebase" archive="someurl" width=200 height=15 id="applet">
	<param name=font value="Verdana,,12">
	<param name=target value="_self">
	<param name=background value="#FFFFFF">


As you see, I first set an absolute width to the applet and onload I read the 
width of the parent td, and as I know that there is just another image with a 
width of 416 I can set the applet also to an absolute width so both elements 
will cover the full td width. Works also in ie. 6 (maybe also with IE. 5+).
This will be fixed in jre1.5
Assignee: joshua.xia → kyle.yuan
Regarding width=0 height=0:

I've found that up to 1.4.2_beta, width=0 height=0 applets would load, but from
1.4.2_03 and 1.5.0 both fail to load applets with width=0 and height=0.

See bug 243321 comment 7

While I'm not sure of the "legality" of having applets with zero sizes, it
certainly is useful in combination with LiveConnect.  (but not critical, because
the applet can be hidden in other ways).

In order to support applet with relative width and height, we have to reject 0 
width or 0 height. Since browser side will pass 0 width(heoght) in case when the 
applet is shown with relative width and height. Before 1.4.2_03, I believe the 
relative width/height can't be shown in some cases.
Blocks: 233546
Whiteboard: fixed_in_tiger
*** Bug 240314 has been marked as a duplicate of this bug. ***
now it's fixed in jre 1.5.
Closed: 18 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.