Closed Bug 41656 Opened 25 years ago Closed 23 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: 23 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: