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

RESOLVED FIXED in mozilla1.1alpha

Status

()

Core
Layout: HTML Frames
P3
normal
RESOLVED FIXED
17 years ago
13 years ago

People

(Reporter: violaine.lebeaupin, Assigned: John Keiser (jkeiser))

Tracking

({compat, testcase})

Trunk
mozilla1.1alpha
compat, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm-] [DIGBug])

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
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>
Created attachment 9699 [details]
testcase
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

Comment 3

17 years ago
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

Comment 4

17 years ago
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

17 years ago
> 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

17 years ago
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

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

Comment 8

17 years ago
Thanks for the above comment Chris, that's just what I was looking for!

Comment 9

17 years ago
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

Comment 10

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

Comment 11

17 years ago
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

Updated

17 years ago
Keywords: testcase

Updated

17 years ago
Keywords: rtm

Comment 12

17 years ago
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-]

Comment 14

17 years ago
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

17 years ago
But since Nav and IE both support height= on tables, we do so in quirks mode.

Comment 16

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

Comment 17

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

Comment 18

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

Comment 19

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

Comment 20

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

Comment 21

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

Comment 22

17 years ago
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

17 years ago
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

Updated

17 years ago
Target Milestone: Future → mozilla0.9.1
*** Bug 69191 has been marked as a duplicate of this bug. ***

Comment 26

17 years ago
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

17 years ago
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>
Created attachment 30963 [details]
testcase: iframe in table cell

Updated

17 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.3

Comment 31

16 years ago
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

16 years ago
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

16 years ago
Correction on URL:
http://op.virtualave.net/MapEditor/mapeditor.html

Comment 34

16 years ago
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

16 years ago
Adding note in status whiteboard for DIG tracking purposes.
Whiteboard: [rtm-] → [rtm-] [DIGBug]

Comment 36

16 years ago
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

16 years ago
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 38

16 years ago
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

Updated

16 years ago
Blocks: 104166

Comment 41

16 years ago
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

16 years ago
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

16 years ago
Created attachment 54791 [details]
testcase: 100% height iframe in a 100% height table cell

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 44

16 years ago
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

16 years ago
Created attachment 59380 [details]
Table example with % on td and iframe but not on table itself

Comment 46

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

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 47

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

Comment 48

16 years ago
*** 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

Updated

16 years ago
Target Milestone: mozilla0.9.8 → mozilla1.1

Comment 50

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

Comment 51

16 years ago
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.

Comment 53

16 years ago
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

16 years ago
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

16 years ago
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
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 57

13 years ago
*** Bug 289116 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.