Last Comment Bug 41656 - (table/iframe) % height NOT ignored in block with no height specified
: (table/iframe) % height NOT ignored in block with no height specified
Status: RESOLVED FIXED
[rtm-] [DIGBug]
: compat, testcase
Product: Core
Classification: Components
Component: Layout: HTML Frames (show other bugs)
: Trunk
: All All
: P3 normal with 5 votes (vote)
: mozilla1.1alpha
Assigned To: John Keiser (jkeiser)
: Amarendra Hanumanula
Mentors:
: 42524 48146 54858 55874 56512 56718 61405 62136 69191 75901 85912 113222 130325 289116 (view as bug list)
Depends on:
Blocks: 104166
  Show dependency treegraph
 
Reported: 2000-06-06 02:55 PDT by violaine.lebeaupin
Modified: 2005-04-05 07:06 PDT (History)
20 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (146 bytes, text/html)
2000-06-06 08:45 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details
testcase: iframe in table cell (161 bytes, text/html)
2001-04-15 21:33 PDT, Andreas M. "Clarence" Schneider
no flags Details
testcase: 100% height iframe in a 100% height table cell (254 bytes, text/html)
2001-10-23 16:13 PDT, Nisheeth Ranjan
no flags Details
Table example with % on td and iframe but not on table itself (155 bytes, text/html)
2001-11-27 13:33 PST, hans_k_97
no flags Details

Description violaine.lebeaupin 2000-06-06 02:55:40 PDT
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>
Comment 1 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-06-06 08:45:13 PDT
Created attachment 9699 [details]
testcase
Comment 2 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-06-06 08:47:06 PDT
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.
Comment 3 Eric Pollmann 2000-06-06 14:59:38 PDT
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?
Comment 4 karnaze (gone) 2000-06-06 16:37:13 PDT
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).
Comment 5 Eric Pollmann 2000-06-07 21:53:05 PDT
> 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?
Comment 6 karnaze (gone) 2000-06-08 09:05:39 PDT
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.
Comment 7 Eric Pollmann 2000-06-14 13:38:22 PDT
*** Bug 42524 has been marked as a duplicate of this bug. ***
Comment 8 Eric Pollmann 2000-06-14 13:41:52 PDT
Thanks for the above comment Chris, that's just what I was looking for!
Comment 9 Eric Pollmann 2000-07-31 11:22:11 PDT
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.
Comment 10 Jeffrey Baker 2000-08-09 09:15:52 PDT
*** Bug 48146 has been marked as a duplicate of this bug. ***
Comment 11 Ross Lombardi 2000-08-10 12:42:27 PDT
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?
Comment 12 Eric Pollmann 2000-09-29 17:35:58 PDT
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!
Comment 13 Kevin McCluskey (gone) 2000-10-02 15:10:19 PDT
Marking rtm-. Just enough time to fix it for this release.
Comment 14 Karl Ove Hufthammer 2000-10-11 11:41:35 PDT
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 --
  >

Comment 15 karnaze (gone) 2000-10-11 11:50:48 PDT
But since Nav and IE both support height= on tables, we do so in quirks mode.
Comment 16 Asa Dotzler [:asa] 2000-11-02 19:16:43 PST
*** Bug 56512 has been marked as a duplicate of this bug. ***
Comment 17 Asa Dotzler [:asa] 2000-11-02 19:57:26 PST
*** Bug 56718 has been marked as a duplicate of this bug. ***
Comment 18 Loco 2000-11-16 17:18:43 PST
*** Bug 54858 has been marked as a duplicate of this bug. ***
Comment 19 Loco 2000-11-16 17:20:48 PST
*** Bug 55874 has been marked as a duplicate of this bug. ***
Comment 20 Asa Dotzler [:asa] 2000-11-28 19:41:39 PST
*** Bug 61405 has been marked as a duplicate of this bug. ***
Comment 21 Eric Pollmann 2000-12-06 19:11:02 PST
*** Bug 62136 has been marked as a duplicate of this bug. ***
Comment 22 Robert Dettmann 2000-12-14 01:42:11 PST
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 ?
Comment 23 Eric Pollmann 2000-12-14 10:21:51 PST
I think someone just noticed this bug is a 'mostfreq' and should get fixed asap.
 :)  Thanks.
Comment 24 ekrock's old account (dead) 2001-01-18 13:21:43 PST
Nom. nsbeta1 as this is clearly impacting a significant number of real-world
pages, judging by the number of DUPs.
Comment 25 Andreas M. "Clarence" Schneider 2001-02-17 09:15:41 PST
*** Bug 69191 has been marked as a duplicate of this bug. ***
Comment 26 k.dambekalns 2001-02-27 13:01:41 PST
OK - so height is an unsupported attribute an table. But it _is_ possible to
specify height using CSS2. So please support at least that...
Comment 27 Amarendra Hanumanula 2001-03-22 13:52:30 PST
QA Contact update
Comment 28 Andreas M. "Clarence" Schneider 2001-04-15 20:59:09 PDT
*** Bug 75901 has been marked as a duplicate of this bug. ***
Comment 29 Andreas M. "Clarence" Schneider 2001-04-15 21:31:27 PDT
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>
Comment 30 Andreas M. "Clarence" Schneider 2001-04-15 21:33:13 PDT
Created attachment 30963 [details]
testcase: iframe in table cell
Comment 31 Kevin Ar18 2001-05-14 20:21:27 PDT
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).
Comment 32 Kevin Ar18 2001-05-14 20:28:56 PDT
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
Comment 33 Kevin Ar18 2001-05-14 20:30:50 PDT
Correction on URL:
http://op.virtualave.net/MapEditor/mapeditor.html
Comment 34 yjseo 2001-07-02 13:16:30 PDT
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 :)
Comment 35 Kirk Parsons 2001-07-05 17:36:48 PDT
Adding note in status whiteboard for DIG tracking purposes.
Comment 36 clayton 2001-07-10 10:01:51 PDT
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!
Comment 37 Blake Ross 2001-07-31 10:06:51 PDT
Missed 0.9.3.
Comment 38 chris hofmann 2001-08-28 13:15:45 PDT
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
Comment 39 Kevin McCluskey (gone) 2001-10-04 16:18:17 PDT
Moving to Mozilla0.9.6
Comment 40 Kevin McCluskey (gone) 2001-10-05 14:22:37 PDT
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Comment 41 hans_k_97 2001-10-17 20:08:25 PDT
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).
Comment 42 Nisheeth Ranjan 2001-10-23 16:11:24 PDT
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!
Comment 43 Nisheeth Ranjan 2001-10-23 16:13:12 PDT
Created attachment 54791 [details]
testcase: 100% height iframe in a 100% height table cell
Comment 44 hans_k_97 2001-11-27 13:31:27 PST
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.
Comment 45 hans_k_97 2001-11-27 13:33:39 PST
Created attachment 59380 [details]
Table example with % on td and iframe but not on table itself
Comment 46 Dimitrios 2001-12-03 11:01:22 PST
*** Bug 113222 has been marked as a duplicate of this bug. ***
Comment 47 Håkan Waara 2001-12-26 06:05:42 PST
*** Bug 85912 has been marked as a duplicate of this bug. ***
Comment 48 Chris Petersen 2002-01-04 11:36:57 PST
*** Bug 118036 has been marked as a duplicate of this bug. ***
Comment 49 Kevin McCluskey (gone) 2002-01-30 11:08:05 PST
Bulk re-assigning all of Eric's HTMLFrame bugs to John.
Comment 50 Amarendra Hanumanula 2002-03-12 11:13:42 PST
*** Bug 130325 has been marked as a duplicate of this bug. ***
Comment 51 Kevin Ar18 2002-03-23 16:08:24 PST
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.
Comment 52 Sören 'Chucker' Kuklau (gone) 2002-03-23 16:14:08 PST
Please refrain from posting comments like #51 . The do nothing but annoy the
developers. They do not help in any way.
Comment 53 Kevin Ar18 2002-03-23 20:39:54 PST
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.
Comment 54 Bernd 2002-03-24 07:34:58 PST
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.
Comment 55 Kevin Ar18 2002-03-27 09:05:59 PST
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?
Comment 56 Kevin McCluskey (gone) 2002-06-07 16:47:43 PDT
Closing this bug. If there are additonal issues please file new bugs with
specific testcases that fail.
Comment 57 :Gijs Kruitbosch (away 26-29 incl.) 2005-04-05 07:06:52 PDT
*** Bug 289116 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.