Closed Bug 211530 Opened 21 years ago Closed 21 years ago

Mozilla can not display Java applet correctly with relative "height" attribute

Categories

(Core :: Layout: Block and Inline, defect)

defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: joshua.xia, Unassigned)

References

()

Details

Steps to reproduce:
1.Launch the Mozilla1.4
2.Open http://www.mozilla.org/quality/browser/front-end/testcases/oji/test7.html.
3.The applets with height=10% or 5% or 3% can't work as relative "height"
attriibute.
regression from April 8 2003 to April 15 2003.
see #191246
Severity: normal → major
Priority: -- → P2
regression from April/11 2003 to April/12 2003
(layout/html/base/src/nsObjectFrame.h and
layout/html/base/src/nsObjectFrame.cpp).
see #191246

It is do absolutely relate to patch:
http://bugzilla.mozilla.org/attachment.cgi?id=119582&action=view

Please check it asap.
Thanks!
Depends on: 191246
Wrong component, and as I said, we should only "fix" this if it's breaking a lot
of sites out there -- the behavior the testcase claims is "correct" is not
correct per the CSS spec.
Assignee: position → block-and-inline
Component: Layout: R & A Pos → Layout: Block & Inline
Priority: P2 → --
Is this the same as bug 208550?
*** Bug 208550 has been marked as a duplicate of this bug. ***
As has already been said, this is invalid.  A quirk could be implemented, but
only if significant numbers of real-world sites depend on it.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
*** Bug 224187 has been marked as a duplicate of this bug. ***
*** Bug 224129 has been marked as a duplicate of this bug. ***
I don't seem to understand why it's invalid. I don't use any CSS in my page, and I 
can't find anything in the HTML 4.01 or CSS spec saying height should not work in 
this case. In addition, I don't know how to do a fullsize-applet for various screen 
resolutions that avoids even more browser-dependent and thus buggy JavaScript 
code. 
> I don't use any CSS in my page

You use the "height" attribute.  Mozilla is a CSS browser -- presentational
attributes in HTML are mapped into equivalent CSS.  Hence you are effectively
using "height: 100%" on that element.

> CSS spec saying height should not work in  this case.

It does work.  A percentage height will be that percentage of the parent height
... unless the parent height is "auto".  In that case, percentage heights are
treated as "auto".  This is clearly described at
http://www.w3.org/TR/CSS21/visudet.html#propdef-height

So if the parent has no explicit height, "height: 100%" is equivalent to not
specifying a height at all.

Now we realize that a lot of sites depend on the NS4/IE way of doing this. 
Which is why we violate the CSS spec in quirks mode to make this work.  But your
page claims to be XHTML (not that it's well-formed XHTML, mind you), which is a
recent enough doctype that the page author should be aware of the CSS
specification and the way CSS layout works, and hence we use standards-compliant
layout on that page.
> So if the parent has no explicit height, "height: 100%" is equivalent to not 
> specifying a height at all. 
 
...which means the default, "auto" is taken. But "auto" doesn't mean the browser 
should take some random value: 
 
"The height depends on the values of other properties." 
 
Unspecified values are treated as 0, so the auto-result (window height minus 
border, top, bottom etc.) should be the same as window height, shouldn't it? 
 
 
<applet> is a replaced element.  So auto height means intrinsic height.  See
http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height

What is the intrinsic height of an <object>?  Intrinsic means it should be
completely independent of the rest of the page layout....  So the rendering
should be identical to the rendering when height is not specified at all (see
comment 10 again).  If we had a way to ask the applet for an intrinsic height,
we would, but we don't.  So we do in fact have to just make up an intrinsic
height.  For compat reasons, the intrinsic height is 240px for <applet> and
<embed> and 0 for <object> (since that's what IE does if you set no height attr).
Also note that I don't know where the "window height minus border, top, bottom
etc." comes from... The parent of the <object> is <body> and the height of
<body> is auto (and certainly not window height).
*** Bug 226315 has been marked as a duplicate of this bug. ***
This is not helpful behavior. 

If a page has no real height then frames specifying a 50% or 100% height would
not work either.  There would be no point in specifying a height in percent for
any object.  

This is a nonsense, surely in this type of case the height should be taken to be
the height of the browser window.

As a matter of interest I have added the applet to a table with a fixed height,
one would expect the percentage height to work as the height is now known.

Unfortunately this sets the height to 240 as well.

<table width="100%" height="500">
  <tbody>
    <tr>
      <td>
<b>applet height=10%</b><br>
<applet align="left" height="10%" width="400" code="JitterText.class" codebase=".">
</applet>
      </p></ul>
      </td>
    </tr>
  </tbody>
</table>
*** Bug 277294 has been marked as a duplicate of this bug. ***
Just to complement this bug.
The 2 testcase-webpages
<object> with relative height:
http://www.mozilla.org/quality/browser/front-end/testcases/oji/objtest7.html
and
<applet> with relative height:
http://www.mozilla.org/quality/browser/front-end/testcases/oji/test7.html
have been updated according to explanations provided in comment #10 and comment #12 in this bug. See bug 392221 for more info.
You need to log in before you can comment on or make changes to this bug.