Closed Bug 41656 Opened 24 years ago Closed 22 years ago

(table/iframe) % height NOT ignored in block with no height specified

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.1alpha

People

(Reporter: violaine.lebeaupin, Assigned: john)

References

Details

(Keywords: compat, testcase, Whiteboard: [rtm-] [DIGBug])

Attachments

(4 files)

testcase
146 bytes, text/html
Details
testcase: iframe in table cell
161 bytes, text/html
Details
testcase: 100% height iframe in a 100% height table cell
254 bytes, text/html
Details
Table example with % on td and iframe but not on table itself
155 bytes, text/html
Details 
I use Mozilla 16, release of 2nd June.
When I use a ...% as value of attribute "Height" to iframe's tag, the height is 
0. (width works correcly)
If I use a value (HEIGHT=500), it's work.

My case test :
<HTML>
  <div>
    <iframe WIDTH="100%" HEIGHT="100%" src="coucou.html"></iframe>
  </div>			
</HTML>
Confirming bug.  I'm not sure what a HEIGHT="...%" *should* do on a child of an 
element without an explicit height.  If there's precendent on other browsers, 
then you might want to follow that for HTML height (but not CSS height).

However, I think it's perfectly legitimate to ignore HEIGHT if it's a 
percentage in such cases.  However, that's not what's happening now -- it's 
being set to 0 instead.  Confirming bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
CC'ing Chris because the CalcQuirkContainingBlockHeight logic is the same as is 
used for % height tables.  In IE, both tables and iframes will take up 100% of 
the viewport height in this case.

Chris, could a modification to CalcQuirkContainingBlockHeight take this into 
account?
Status: NEW → ASSIGNED
Keywords: compat
OS: Windows 95 → All
Hardware: PC → All
Summary: Height="...%" in IFRAME's tag → (table/iframe) % height ignored in block tags with no height specified
Target Milestone: --- → M19
Yes, you could make <IFRAME>s work like tables since IE does (and Nav doesn't 
support them). However, it might be informative for you to figure out why the 
height is 0 currently. You might decide to make the IE behavior a quirk and 
ignore the % height in standard mode (but 0 is not an acceptable height).
> Yes, you could make <IFRAME>s work like tables since IE does (and Nav doesn't
> support them). However, it might be informative for you to figure out why the
> height is 0 currently. You might decide to make the IE behavior a quirk and
> ignore the % height in standard mode (but 0 is not an acceptable height).

Actually, when fixing the frameset resizing bug, I checked in changes to make 
iframes act like tables (in nsHTMLReflowState::ComputeContainingBlockRectangle, 
both call CalcQuirkContainingBlockHeight)  This fixes most simple percentage 
height cases, using the viewport if needed to emulate IE.

The problem with this test case is that CalcQuirkContainingBlockHeight returns 0 
for the containing block height because as it goes up the parent chain, it 
figures out that the iframe/table is not inside a <body>, but a <div>.  It 
returns 0 for both tables and iframes (I substituted a table for an iframe and 
traced through, it gets back zero too.)

How do tables know to ignore this mComputedHeight of 0?  What should iframes 
do? Could we relax CalcQuirkContainingBlockHeight somehow to accomodate this 
case?
Returning a 0 height is not a great idea since the table/iframe might be 0 
height, but I recommend that you not change that and break tables without much 
testing. Instead for the time being, try testing for 0 in iframes. Tables 
consider the mComputedHeight to be a minimum height so if it is 0, then the 
table becomes as tall as it would naturally considering rows, cells, etc. 

The real issue is whether or not the function should really stop if it 
encounters a parent block that is not the body. I don't have enough test cases 
to answer that, but I recall that Nav appeared to behave this way. If you can 
demonstrate that Nav and/or IE always use the viewport even if there is a block 
in between, then the function could be made to never return 0.
*** Bug 42524 has been marked as a duplicate of this bug. ***
Thanks for the above comment Chris, that's just what I was looking for!
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: M19 → Future
*** Bug 48146 has been marked as a duplicate of this bug. ***
How can this bug be put off so long? It's the bane of any "web-page designer's"
existence... it's a bug in Netscape since the first version I ever used and is
still a bug in Gecko. Adding myself to CC because I really think this is more
important than everyone here thinks it is. If im out of line, then i'll find out
this weekend when I finally download the source and play with it. Will height
work correctly if it's set inside another table with an integer height specified?
Summary: (table/iframe) % height ignored in block tags with no height specified → (table/iframe) % height NOT ignored in block with no height specified
Keywords: testcase
Keywords: rtm
Ross, I understand your concern.  I'd love to devote the time needed to fix this
bug.  Unfortunately, we're trying to buckle down to ship a final release version
of the browser in the near future, and priorities demand that some other, even
more egregious behaviour, be addressed first. (e.g., Frames loading the wrong
URL, crashes, form posting not working at all, security bugs, ...)

If you can find the time or resources needed to fix this bug, or present
examples of real-world, top100 pages that display incorrectly because of this
bug, it stands a much higher chance of being fixed for the final product. 
Please let me know if I can help in any way if you do decide to poke around the
source on your own.  Thanks!
Marking rtm-. Just enough time to fix it for this release.
Whiteboard: [rtm-]
FYI, 'height' on tables (not iframes) should be ignored anyway, since there is 
no 'height' attribute on the table element in HTML (neither in Strict nor 
Transitional).

<!ELEMENT TABLE - -
     (CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)>
<!ATTLIST TABLE                        -- table element --
  %attrs;                              -- %coreattrs, %i18n, %events --
  summary     %Text;         #IMPLIED  -- purpose/structure for speech output--
  width       %Length;       #IMPLIED  -- table width --
  border      %Pixels;       #IMPLIED  -- controls frame width around table --
  frame       %TFrame;       #IMPLIED  -- which parts of frame to render --
  rules       %TRules;       #IMPLIED  -- rulings between rows and cols --
  cellspacing %Length;       #IMPLIED  -- spacing between cells --
  cellpadding %Length;       #IMPLIED  -- spacing within cells --
  >


But since Nav and IE both support height= on tables, we do so in quirks mode.
*** Bug 56512 has been marked as a duplicate of this bug. ***
*** Bug 56718 has been marked as a duplicate of this bug. ***
*** Bug 54858 has been marked as a duplicate of this bug. ***
*** Bug 55874 has been marked as a duplicate of this bug. ***
*** Bug 61405 has been marked as a duplicate of this bug. ***
*** Bug 62136 has been marked as a duplicate of this bug. ***
Ok, do you work for a really practice solution or do you mark only duplicate 
reports. Here is bureaucracy like in a office. Do have more people for 
management than for product development ?
I think someone just noticed this bug is a 'mostfreq' and should get fixed asap.
 :)  Thanks.
Keywords: mostfreq
Nom. nsbeta1 as this is clearly impacting a significant number of real-world
pages, judging by the number of DUPs.
Keywords: nsbeta1
Target Milestone: Future → mozilla0.9.1
*** Bug 69191 has been marked as a duplicate of this bug. ***
OK - so height is an unsupported attribute an table. But it _is_ possible to
specify height using CSS2. So please support at least that...
QA Contact update
QA Contact: petersen → amar
*** Bug 75901 has been marked as a duplicate of this bug. ***
Even this <iframe> has height 0:

<table border=1><tr>
 <td style="height:400px;width:600px">
  <iframe src="http://www.mozilla.org/" width="100%" height="100%"></iframe>
 </td></tr></table>
Target Milestone: mozilla0.9.1 → mozilla0.9.3
This site relys on this bug to be fixed in order for it to even be usable in 
Mozilla.
I'm reporting this site on the behalf of the owner of it.  He was complaining 
about it not working in Netscape 6.

http://www.crownvic.net

I consider this a major bug since lots of people use percentages in iframes 
instead of an absolute pixel size (including me).
My site makes use use percentages in height and width of IFRAME as well.
http://op.virtualave.net/

actually the map editor on my site makes use of percentanges in the IFRAME.
http://op.virtualve.net/MapEditor/mapeditor.html
Currently there are so many sites that uses <IFrame height=100% ... >
especaily in Korea. I think dreamweaver makes this code.
Please fix this problem as soon as possible.

Example problem sites. http://sports.chosun.com (Korean :)
Adding note in status whiteboard for DIG tracking purposes.
Whiteboard: [rtm-] → [rtm-] [DIGBug]
Eric, the DIG team would like a fix for this, but it's not an outright blocker
for them.  If you have time and the fix looks safe......    Thanks!
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
eric is no longer around.  
we need some more time to figure out who can own this bug.
anybody have ideas?

unlikley this will make 0.9.4
Keywords: mostfreq
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Moving to Mozilla0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Assignee: pollmann → evaughan
Status: ASSIGNED → NEW
Blocks: 104166
For lack of other attention to this bug, I'm going to be poking around the
source.  No guarantees- if you want to work on it, you'll probably be able to
fix faster than me so please go ahead and just let me know.

First attachment (IFRAME in DIV) appears to work with 2001101603 on Win98, 2nd
does not (IFRAME in Table).
Eric, this probably *is* a iframe within a table cell problem and not a general
block within a table cell bug.  Attaching the test case that displays wrongly in
Netscape 6.1.  I tried replacing the iframe with a DIV tag of width 100% and
height 100% and the page laid out fine.  To try it out, replace the IFRAME in
the attached test case with:

<DIV width="100%" height="100%">
This is a test
</DIV>
You will see that the DIV gets assigned a height equal to the entire height of
the window as it should.  If you replace the DIV with an IFRAME, however, the
IFRAME gets a height of 0 and does not show up.

So, is this your problem or a table layout problem?  Lets try to get this to the
correct owner as soon as possible!  :-)

Thanks for your help on this!
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.7
All test cases for this bug now work, except for the virtualave one:
http://op.virtualave.net/MapEditor/mapeditor.html

See new test case.  If you include height="100%" on the table itself, the iframe
expands, but if you just use <table> then the old behavior appears.
*** Bug 113222 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 85912 has been marked as a duplicate of this bug. ***
*** Bug 118036 has been marked as a duplicate of this bug. ***
Bulk re-assigning all of Eric's HTMLFrame bugs to John.
Assignee: eric → jkeiser
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.8 → mozilla1.1
*** Bug 130325 has been marked as a duplicate of this bug. ***
This bug is a major blocker for my site - I have no easy way around it.  I 
hope it can be fixed as soon as possible.
Please refrain from posting comments like #51 . The do nothing but annoy the
developers. They do not help in any way.
Would it be appropriate to respond?

To all, particularly the people working on this issue:
I'm sorry for the post and apologize for the rather harsh comments.  I know it 
is discouraging to hear people complain about anthing you've worked on, so 
again I'm sorry.
To Sören and the others:
I hope that you won't have any harsh feelings toward me in the future as we 
discuss this and other bugs.
We render the last testcase as IE6 and opera do. The issue with
http://op.virtualave.net/MapEditor/mapeditor.html is in my oppinion a evangelism
issue:

Error: document.all has no properties
Source File: http://op.virtualave.net/MapEditor/mapeditor.html
Line: 210

 205: function centerLayers () {
 206:   var layers = "Wopenmap,Wnewmap,Wexporttext";
 207:   var layers_array = layers.split(",");
 208:   var i=0;
 209:   while(i < layers_array.length) {
 210:     var w = document.all[layers_array[i]].style.width;
 211:     var h = document.all[layers_array[i]].style.height;

This site uses heavily layer and document.all, so instead of ranting
"I have no easy way around it." , make your page standards compliant, see
http://mozilla-evangelism.bclary.com/fep/ for help.

I don't understand why we can't close this bug or send it over to evangelism.

ps: I hope the message is clear don't rant in bugs...,there are some experienced
flamers around.
This site uses heavily layer and document.all, so instead of ranting
"I have no easy way around it." , make your page standards compliant, see
http://mozilla-evangelism.bclary.com/fep/ for help.

You are quite right, and that is actually what I was planning to do once I 
could find the infomation, so thanks for the link.

This bug isn't a site specific thing (again sorry for my post).
From what I was able to determine, thanks to another bug report elsewhere, it 
seems to occur when an iframe is nested within two or more tables that have a 
height=100% and the iframe is height=100%.
The following testcase illustrates this:
http://bugzilla.mozilla.org/attachment.cgi?id=74249&action=view


The bug also occurs when an iframe of height=100% is within a td with 
height=100%.  Even Internet Explorer has this bug.
The following testcase demonstrates this:
http://bugzilla.mozilla.org/attachment.cgi?id=59380&action=view


BTW, is Bug 131020 a duplicate?
Closing this bug. If there are additonal issues please file new bugs with
specific testcases that fail.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 289116 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: