[strict] Applet/Object data is not rendered when Height attribute is assigned a percentage

VERIFIED FIXED in mozilla1.2alpha



17 years ago
15 years ago


(Reporter: chrispetersen, Assigned: karnaze)


({crash, regression, testcase})

crash, regression, testcase

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PL2:NA], URL)


(11 attachments, 6 obsolete attachments)

709 bytes, text/xml
447 bytes, text/xml
535 bytes, text/html
538 bytes, text/html
3.31 KB, patch
Details | Diff | Splinter Review
1.12 KB, patch
Details | Diff | Splinter Review
606 bytes, text/html
681 bytes, text/html
698 bytes, text/html
3.74 KB, patch
: review+
: superreview+
Details | Diff | Splinter Review
739 bytes, text/html


17 years ago
Build: 2002-03-14-08
Platform : All
Expected Results: Object content should render based on the height (percent)
What I got: Object content is not rendered 

Steps to reproduce:

1) Download both attached test cases
2) Open object_percent_w_h_text.xml
3) The test case contains two objects. First object doesn't render it's content
but the second object does.

Comment 1

17 years ago
Created attachment 74246 [details]
Object test case using percentages for width and height

Save this testcase

Comment 2

17 years ago
Created attachment 74247 [details]
XML file that is inserted into first testcase

Save this testcase

Comment 3

17 years ago
Changing Priority to P3
Priority: -- → P3
Hint: if you first upload the attachments, get their URLs, and upload the actual
test file with the correct URLs we wouldn't need to download the tests first and
edit them by hand to include the correct filenames...
Target Milestone: --- → mozilla1.1alpha

Comment 5

17 years ago
After further research, this problem is related to standards mode. If I place a
strict DTD in a HTML file, I get the same results.

See the two applet test attached:

One with WIDTH percent and the other with HEIGHT percent.

Comment 6

17 years ago
Created attachment 77506 [details]
Width attribute specified at 50%.

HTML Doctype is STRICT. Width is percent and applet is displayed.

Comment 7

17 years ago
Created attachment 77509 [details]
Height attribute is specified at 50%

HTML Doctype is STRICT. Height is percent and applet is not displayed even
thought applet is initialized.

Comment 8

17 years ago
This seems to be a regression since the applet height test is working in a older
trunk build (Feb 20th build)
Keywords: regression

Comment 9

17 years ago
Changing summary
Summary: Object data is not rendered when Height attribute is assigned a percentage → Applet/Object data is not rendered when Height attribute is assigned a percentage
Reassigning to layout. My question is: is this intentional in strict mode?
Assignee: heikki → attinasi
Component: XML → Layout
Keywords: xhtml
Priority: P3 → --
Target Milestone: mozilla1.1alpha → ---


17 years ago
Priority: -- → P2
Target Milestone: --- → Future

Comment 11

17 years ago
Thanks a good question... It did work before but maybe we were doing the wrong
thing ? Need to research .

Comment 12

17 years ago
Taking bug...

Might be a regression or fallout from bug 106602.
Summary: Applet/Object data is not rendered when Height attribute is assigned a percentage → [XML] Applet/Object data is not rendered when Height attribute is assigned a percentage
Target Milestone: Future → ---
This is not XML specific, modifying Summary to reflect this.

Also really reassigning to Peter.
Assignee: attinasi → peterlubczynski
Summary: [XML] Applet/Object data is not rendered when Height attribute is assigned a percentage → Applet/Object data is not rendered when Height attribute is assigned a percentage

Comment 14

17 years ago
This bug is a dup of bug 108831. Either one of these two can be closed

Comment 15

17 years ago
Oops, these may be not quite dups. Bug 108831 is about applet with percent height
attribute not displayed in table...

Comment 16

17 years ago
*** Bug 108831 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
nominating nsbeta1
Keywords: mozilla1.0, nsbeta1
Hardware: Macintosh → All
Summary: Applet/Object data is not rendered when Height attribute is assigned a percentage → [strict] Applet/Object data is not rendered when Height attribute is assigned a percentage

Comment 18

17 years ago
removing nominations, I need some clarification if this is really a bug

I got a tip that in strict mode, the body's height is zero. Therefore, it looks
like we are doing the right thing in these testcase by making the height of the
applet 0. If you put a height on the BODY, the applet gets displayed the right

Could someone more familar with XHTML and strict mode advise?
Keywords: mozilla1.0, nsbeta1

Comment 19

17 years ago
Since this works fine in quirks mode, which most pages are rendered in, I am 
pushing out to 1.1. The exposure to this regression is relatively low
Target Milestone: --- → mozilla1.1alpha
The body's height isn't really zero, but according to CSS, percentage heights
shouldn't do anything if the parent's height is 'auto':


Tables have a bunch of code to make HTML-specified percentage heights act
differently from this, though.
Target Milestone: mozilla1.1alpha → ---
Target Milestone: --- → mozilla1.1alpha
Created attachment 79484 [details] [diff] [review]
possible fix

This fixes the testcase.  What will it do to the quirks mode case?  (What was
our behavior in the quirks mode case?)

Comment 22

17 years ago
I don't see anything on
http://www.w3.org/TR/REC-CSS2/visudet.html#the-height-property that says that
% height shouldn't do anything if  parents' height is auto. 
It says:
"The percentage is calculated with respect to the height of the generated box's
containing block. If the height of the containing block is not specified
explicitly (i.e., it depends on content height), the value is interpreted like
'auto'. "
And auto height is an intrinsic height, isn't it?

Also, applet's height parameter has nothing common to css
What the reasons of not showing applet in the following html :
<table border="1">
<td><applet code="pabanner.class" width=50% height=50%></applet></td>

Also note the asymmetry between width and height params.
Mozilla correctly compute width, but not height
For some things, 'auto' is an intrinsic height.  However, it's not 50% of
anything if it was specified as 50%.

Does the patch not fix that testcase?

Comment 24

17 years ago
Applet inside of table? Nope.

It still hits last else and its meaning completely escapes me
+    else if (NS_UNCONSTRAINEDSIZE != aReflowState.mComputedHeight)
+      // Unconstrained percent case.
+      aMetrics.height = aReflowState.mComputedHeight;
+    else if (mFrames.FirstChild())
+      // This will be used only by |HandleChild|.  Otherwise it wouldn't
+      // be an appropriate result from |GetDesiredSize| (which is also a
+      // virtual method on |nsLeafFrame|, but |nsObjectFrame| doesn't
+      // derive from |nsLeafFrame|).
+      aMetrics.height = NS_UNCONSTRAINEDSIZE;
+    else
+      aMetrics.height = 0;
       ^^^^^^^^^^^^^^^^^^^ why zero????
In the old html world 50% height in unconstrained table means 50% of content
(browser window, whatever) area, isn't it?

Comment 25

17 years ago
Plugins don't really have any way currently of telling the browser their
"intrinsic" size. I think that's what nsIPluginInstancePeer::SetWindowSize and
NPPVpluginWindowSize were intended for.

Comment 26

17 years ago
Proposed patch also doesn't fix xhtml testcase. I tried <applet height=90%> (w/o
tables) with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
Zero because the old code said zero, I can't think of anything better, and we
have to pick something.

We have some hacky code somewhere to do the percent-in-the-old-world emulation.
 If someone wants to figure out how to use it, go ahead.

Comment 28

17 years ago
Why not to apply percentage to window (content area or whatever it could be
called) size?
That would be incorrect for any height style specified through CSS.  It suggests
we really should be mapping HTML percentages for height to different units.
Note about XHTML testing: there are only two things that make us process XHTML.
The document must have an XML mime type, and the namespace for the elements must
be the XHTML namespace. In other words, if you serve with HTML mime type we will
treat it as regular HTML, and if you serve with XML mime type but forget XHTML
namespace we don't recognize it as XHTML either. So, a DOCTYPE does not matter
at all here.

Comment 33

17 years ago
Since Patrick B. said bug: 119352 is more likely a layout issue, so I close the 
bug: http://bugzilla.mozilla.org/show_bug.cgi?id=119352 
and add more info into this bug.

Seen on Mac OS 10.1.3 (2002-04-16-03-TRUNK) with MRJ v1.0b2.

Steps to reproduce:

1. Launch netscape.
2. Click on this url:

Notice the applets height=10%, applet height=5%, applet height=3% are not

Comment 34

17 years ago
Note, that applets mentioned in comment #33 are inside of unconstrained table.
Quirks mode.

Comment 35

17 years ago
Strange results (on WinXP w/debug build) on pmac's testcase:

* JRE 1.3.1_02 hangs Moz
* JRE 1.4 seems to layout it our correctly in Moz
* IE 6 only renders the top applet
* 4.x doesn't seem to be scaling the applets correctly either

Best results (near perfect) with JRE 1.4 and Moz

Comment 36

17 years ago
Solaris and Linux with java 1.3.1 : only top applet is shown

Comment 37

17 years ago
Just talked this through with karnaze and peterl. With the applet in a table 
where the cell does not have a defined height. Mozilla renders the content the 
same as IE and Opera. Since we are all rendering the test the same, I am not 
convinced this is a bug.

Comment 38

17 years ago
With the applet outside the table, in strict mode - IE and Opera render the 
applet. We do not, since we are not consistent, we should look into a possible 

Comment 39

17 years ago
Chris says this worked on 2/20 builds... broken by 3/14. If we narrow that
window down, maybe we can identify what change caused this... and the reason for
that change...

Comment 40

17 years ago
*** Bug 138786 has been marked as a duplicate of this bug. ***

Comment 41

17 years ago
This appears to be causing a crash in Linux in bug 138768:

if you enter the url of the flash-file ( http://www.deadtroll.com/trollboot.swf )
mozilla doesn't crash. So I saved the html-file and the swf-file to my
home-directory and played a bit with them.

In the original html file is the line
<embed src="trollboot.swf" width="95%" height="95%" align="TOP"
type="application/x-shockwave-flash" play="true">

If you remove the height and the width attribute from this line, mozilla won't
crash and will display the flash-animation.

Hope that helps,

------- Additional Comment #8 From Andrew Schultz 2002-04-21 07:38 -------

#0  0x41af272b in XtAddTimeOut () from /usr/X11R6/lib/libXt.so.6
#1  0x41af2887 in XtAppAddTimeOut () from /usr/X11R6/lib/libXt.so.6
#2  0x452a72cc in morkUsage_g_static_init_done () from 

build 20020415 works, 20020417 does not.
Keywords: nsbeta1

Comment 42

17 years ago
this actually started happening between 20020305 and 20020307.

testcase from bug 138786: atachment 80280

Comment 43

17 years ago
removing myself from cc:


17 years ago
Keywords: testcase

Comment 44

17 years ago
comment 12 is correct... this is a regression from bug 106602.
keyword crash and severity critical since Flash causes a crash (bug 138786)
Severity: normal → critical
Keywords: crash

Comment 45

17 years ago
for attachment 80280 [details], the patch here does not help because mFrames.FirstChild()
is 0.

Comment 46

17 years ago
The applet in the 4th attachment is not showing up because it has a strict dtd 
and CalcQuirkContainingBlockHeight does not get called in nsHTMLReflowState.cpp 
in standard mode. It would be easy to change this, but it would violate the 
standard (but of course we don't display the applet even though IE and Opera 
do, because we support the standard). 

Are there any strong opinions one way or the other?

Comment 47

17 years ago
Standard mode documents should be treated as standard mode documents, as far as
is possible. Can't we just evangelize the author to fix their page? Oh, wait,
it's the US government...

I fear that doing the Quirk-mode computation in strict mode for all elements
would seriously jeopardize the efficacy of the standards, for whatever that is
worth. If we just did it for Object elements it would be less bad though.

Peter, you ripped out some code for bug 106602 - what about using that to
compute the height if the reflow state provides a height of '0'?

Comment 48

17 years ago
Marc -- how would they properly code their pages? No harm in asking htem to fix
their code

Comment 49

17 years ago
note that this is a crasher with Flash.  That is a bug with Flash, but we should
not punish Mozilla users for this if we don't have to.

Comment 50

17 years ago
The page should specify a fixed size for the container of object. They could put
in a DIV with a specific height, for example. Or, they could specify the height
of the object in pixels instead of percent. That would take care of the problem
I think.

Comment 51

17 years ago
I have been unable to reproduce the crash with other .swf flash movies...

Comment 52

16 years ago
I'm seeing a problem which is probably related to this bug, although it is
possibly separate. I find with Mozilla 1.0 RC3 on Windows 2000 that an applet
which: (1) is embedded within a <p> or <div>; (2) expresses its height as a "%";
and (3) has either align="left" or align="right" is displayed within a window
with a height of 0, making it invisible. The applet is apparently running
correctly, but its display cannot be seen.

I do not see this problem with the Linux version of Mozilla.

Time is pressing at the moment, but I shall try to produce a test case in the
next day or two. However, I do see the same symptoms with the existing "Height
attribute is specified at 50%" attachment - that is, the applet runs within a
window of height 0.

Comment 53

16 years ago
Created attachment 86548 [details]
Shows applet height problem in Win32 Mozilla

The applet within this document receives a height of 0 under Mozilla 1.0 on Win

Comment 54

16 years ago
Created attachment 86549 [details]
Does not show applet height problem in Win32 Mozilla

Here the applet displays correctly with Mozilla 1.0 on Win 2K. Note that the
only signficant difference from the preceeding attachment is the way in which
the <p> tag before the applet is closed!

Comment 55

16 years ago
*** Bug 128302 has been marked as a duplicate of this bug. ***

Comment 56

16 years ago
*** Bug 150886 has been marked as a duplicate of this bug. ***

Comment 57

16 years ago
*** Bug 151396 has been marked as a duplicate of this bug. ***

Comment 58

16 years ago
this should have been marked as nsbeta1- already
Keywords: nsbeta1 → nsbeta1-
Adding timeless to cc, he was triggering this bug with a testcase the other 


16 years ago
Whiteboard: [PL2:NA]
Target Milestone: mozilla1.1alpha → mozilla1.0.2

Comment 60

16 years ago
*** Bug 135831 has been marked as a duplicate of this bug. ***

Comment 61

16 years ago
*** Bug 159276 has been marked as a duplicate of this bug. ***

Comment 62

16 years ago
adding nsbeta1+
Keywords: nsbeta1- → nsbeta1+
Target Milestone: mozilla1.0.2 → mozilla1.2alpha

Comment 63

16 years ago
*** Bug 143508 has been marked as a duplicate of this bug. ***

Comment 64

16 years ago
http://www.timeticker.com is another site that has this problem.

Comment 65

16 years ago
This broke between March 6 at 4PM and March 7 at 8AM


Is definitely the prime candidate as it went in during this time.

Comment 66

16 years ago
yes, it is.  see comment 44

Comment 67

16 years ago
This is not a standards issue at all I believe.

Just having <EMBED HEIGHT=100%> causes displaying flash to fail.

Why should this be a standards issue?

Comment 68

16 years ago
*** Bug 140518 has been marked as a duplicate of this bug. ***

Comment 69

16 years ago
This bug has so many testcase, let me try to make it clear.
Testcase 1 and testcase 2 are not suitable here since it is not xhtml specific,
so just skip it.

Testcase 5 and testcase 6 are not suitable here also, they are all in quirk mode.
In Testcase 5, applet is after '<p/>', so when parser make content tree,applet
will be treated as <p>'s childen,just like this
<html><body><p><applet height="50%"..></p>,
if reporter think it is a problem, please file another bug about it, its catalog
should be parser.

Testcase 3 is about width. 

So I think Testcase 4 is suitable here.

Comment 70

16 years ago
Created attachment 95059 [details] [diff] [review]
Patch 0.1

I make patch 0.1 according to comments #c47.
just call quirk method for objectframe in strict mode, 
it wont hurt other frame.


16 years ago
Attachment #86549 - Attachment is obsolete: true


16 years ago
Attachment #86548 - Attachment is obsolete: true

Comment 71

16 years ago
As Testcase 5 and Testcase 6 are caused by "<p/>", they are not suitable here.
I have filed another bug 162441 for it.
So I mark testcase 5 and testcase 6 as obsolete.

Comment 72

16 years ago
*** Bug 138017 has been marked as a duplicate of this bug. ***

Comment 73

16 years ago
Created attachment 96154 [details] [diff] [review]
patch 0.2 for discuss

Comment 74

16 years ago
Patch 0.2 is in the different way from patch 0.1
According to  comment #44, I made patch 0.1

And since this bug is regression of bug 106602
So I made Patch 0.2 for discuss. 

Comment 75

16 years ago
Here is some comments for patch 0.2
The case of bug 106602 is quite different from bug 131065.
bug 106602 is related with percent height objectframe in TableCell, which will
cause special height reflow of table.
nsObjectFrame::Reflow() will be called three times.
During the third reflow(special height reflow), reflowstate will set
mComputedHeight as percent*Containheight there,
then call nsObjectFrame::Reflow().
so in function body of nsObjectFrame::GetDesiredSize(), it will use
mComputerHeight as desired height.

bug 131065 is related with object in unconstraned height.
it will call nsOjectFrame::Reflow() only once, to set desired height in

So patch 0.2 calculate its parentframe, if it is TableCell, follow the logic of
106602 fix.
if not, follow the old logic before fix of bug 106602.

Comment 76

16 years ago
This needs to include nsLayoutAtoms::bcTableCellFrame also. nsTableCellFrame.h
defines the macro IS_TABLE_CELL which you may want to copy.

+      if (fType.get() == nsLayoutAtoms::tableCellFrame) {
+      	if (aReflowState.mComputedHeight != NS_UNCONSTRAINEDSIZE)
+          aMetrics.height = aReflowState.mComputedHeight;
+      }
+      else {

The XXX comments are valid - we are propogating incorrect code here. Also, what
should happen when an object is inside something inside the body and there are
other elements inside the body?
+        nsRect rect;
+        aPresContext->GetVisibleArea(rect);
+        nscoord h = rect.height;
+        // now make it nicely fit counting margins
+        nsIFrame *containingBlock = nsnull;
+        if (NS_SUCCEEDED(GetContainingBlock(this, &containingBlock)) &&
containingBlock) {
+          containingBlock->GetRect(rect);
+          h -= 2*rect.y;
+          // XXX: this math seems suspect to me.  Is the parent's margin really
twice the x-offset?
+          //      in CSS, a frame can have independent top and bottom margins
+          // but for now, let's just copy what we had before
+        }
+        aMetrics.height = NSToCoordRound (factor * h);
+      }
+    }

Comment 77

16 years ago
Created attachment 97159 [details] [diff] [review]
patch 0.21 (add bcTableCellFrame)


<title>HTML Functional -- APPLET - WIDTH=percent</title>
<style type="text/css">
html {background-color: olive}
.pile {
left: 2in;
top: 2in;
width: 3in;
height: 3in;
<p>The banner applet will be displayed with a width of
<div class="pile">
<applet code="parbanner.class"
width="50%"  height="80%">
<param name="message" value="Scrolling banner text !!!" />

<applet code="parbanner.class"
width="50%"  height="80%">
<param name="message" value="Scrolling banner text !!!" />


another testcase for karnaze's comments.
it works fine with patch 0.21


16 years ago
Attachment #96154 - Attachment is obsolete: true


16 years ago
Keywords: review

Comment 78

16 years ago
Created attachment 97619 [details]
test case with body having unequal top an bottom margins

Comment 79

16 years ago
Created attachment 97620 [details] [diff] [review]
revised patch to handle unequal top and bottom margins in containing blocks
Attachment #97159 - Attachment is obsolete: true

Comment 80

16 years ago
The revised patch passes the regression tests. I'm taking the bug to try to get
it checked in before the midnight deadline. 
Assignee: peterlubczynski → karnaze

Comment 81

16 years ago
Created attachment 97644 [details]
test case with absolutely positioned object

Comment 82

16 years ago
Created attachment 97646 [details]
test case with absolutely positioned object
Attachment #97644 - Attachment is obsolete: true

Comment 83

16 years ago
Created attachment 97647 [details]
test case with absolutely positioned div containing object

Comment 84

16 years ago
Created attachment 97654 [details] [diff] [review]
revised patch to handle unequal top/bottom margins and absolute positioning
Attachment #97620 - Attachment is obsolete: true

Comment 85

16 years ago
Comment on attachment 97654 [details] [diff] [review]
revised patch to handle unequal top/bottom margins and absolute positioning

Attachment #97654 - Flags: review+

Comment 86

16 years ago
Comment on attachment 97654 [details] [diff] [review]
revised patch to handle unequal top/bottom margins and absolute positioning

sr=kin@netscape.com ... we really need some generalization so we don't have to
reference table cells directly.
Attachment #97654 - Flags: superreview+

Comment 87

16 years ago
The patch is in.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 88

16 years ago
*** Bug 159276 has been marked as a duplicate of this bug. ***

Comment 89

16 years ago
Verified in the OS X (2002-09-09-08) , Linux (2002-09-09-08) , Windows ME
This caused crash bug 191246.  Can someone please explain to me what the patch
that was checked in was attempting to do?  I have not been able to find anything
so far that it would be doing correctly....

Comment 91

16 years ago
I'd like to reopen this bug, please.  Between released builds 1.1 and 1.2.1,
percentage height within an absolute (or fixed) <DIV> takes the percentage of
the entire window.  Widths work as expected.
The test case #97647 above (test0.html, 
used 100% for heights and so hid the bug.  I'll attach a variant on that which
will make the problem clear:  the applet is given 100% by 100%, and should be
surrounded by the containing DIV's border.

Comment 92

16 years ago
Created attachment 114823 [details]
Example of hosed % heights in absolute DIV

Absolute <DIV> positioned in page, has large border.  Contains a Java <OBJECT>
with 100% x 100% dimensions -- should fill the DIV entirely, and so be
surrounded by border.  In Mozilla 1.2.1 (Win32) the applet's 100% HEIGHT
is calculated against the viewport rather than the DIV; WIDTH is handled
Yeah, see my comments in bug 191246 on how this patch is completely screwed up....

Comment 94

16 years ago
Sorry, I just reread my comment #91 and realized it was somewhat incoherent.

I meant that the change I'm complaining about occurred between 1.1 and 1.2.1.
The regression is particularly noticeable because this same symptom was fixed
between 0.9.9 and 1.0, and I have a page that uses a %-sized <APPLET> within a
fixed <DIV>.

And when I said the previously submitted test case "used 100%" I meant that
the absolute <DIV> in that example was given a height of 100%, as was the
contained <APPLET>, so the symptom was not visible.
*** Bug 193773 has been marked as a duplicate of this bug. ***

Comment 96

16 years ago
Is asking for this bug to be reopened (viz. my report in comment #91) the
wrong thing to do?  Should I open a new bug for this issue instead?  (Or has
one been opened that I haven't been able to find?)
Bug 191246 is apparently related, but doesn't address the broken height-setting
Mike, the fix for bug 191246 will address the broken height setting behavior,
trust me (since it will have to pass all testcases in this bug).
*** Bug 181385 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.