Incorrect size of iframe with width=100% in a bare table cell




17 years ago
3 months ago


(Reporter: jesup, Assigned: john)



Bug Flags:
blocking1.8a1 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [WGATE])


(3 attachments, 1 obsolete attachment)



17 years ago
This bug is in mozilla 1.0 RC2 and probably most others.

See the testcase.  The iframe and it's table cell are narrower than they should
be.  Doing almost anything to the remaining elements makes the problem go away
(the cell with the iframe expands to take all space not in the left-hand column).

From the testcase:
<!-- This iframe is too far right.
     If you put a single character here that isn't in a comment it works,
     or change 100% to an absolute number (451 (640-149) perhaps), or
     change frameborder to 1, or set the table's border=1, or remove the

Comment 1

17 years ago
Created attachment 85494 [details]

Minimal testcase

Comment 2

17 years ago
Same problem with trunk.

Once we fix this, we may want to add it to the regression tests
Whiteboard: [WGATE]
Reassigning to John.
Assignee: attinasi → jkeiser


17 years ago
Keywords: testcase
Priority: -- → P2

Comment 4

17 years ago
John - any progress on this?  have you looked at the testcase?
Bulk moving P1-P5 un-milestoned bugs to future. 
Target Milestone: --- → Future
Component: Layout → Layout: HTML Frames

Comment 6

16 years ago
Is this still valid?

Comment 7

15 years ago
Yes, this is still valid.

I've run into another bug with a piece of web software I'm developing, whereby
an iframe with "align" attribute defined and enclosed in a "div" tag is rendered
with incorrect height and width (usually much smaller than the specified
percentage).  Remove the div tag, and the iframe renders correctly.  Leave the
div tag, but remove the "align" attribute of the iframe and mozilla renders the
iframe correctly.

I've added my comments and a test case to this bug, because they both seem to
revolve around the same issue.  That is, they both deal with percentage-based
width and height values not being applied correctly to an iframe, when certain
other conditions are met.  Please let me know if this is *not* the case and I
need to file a separate bug report.

Comment 8

15 years ago
Created attachment 130910 [details]
another (related) test case

Comment 9

15 years ago
I'm assuming I've come across a related bug with the following web site:

There appear to be some problems translating from percentage geometry to pixel
geometry, possibly linked to the presence of scrollbars.

My screen in 1280x960px.

If I open DOM inspector on the above site and set the DOM inspector browser pane
to at least 400px, the computed height of the root HTML node is an integer
number of pixels.  Below 400px, it is a fractional number of pixel and a
vertical scrollbar appears (needlessly).

A different problem occurs with the horizontal scrollbar.  When
"miscpages/newsindex.htm" is displayed in the iframe in the root document, a
horizontal scroll bar is present for the containing iframe.  When
"miscpages/newsindex.htm" is displayed directly, no scrollbar is displayed.

Comment 10

15 years ago
Created attachment 136687 [details]
Here is a trivial test case

Adding 'style="margin: 0pt"' to the body tag triggers the error.
Comment on attachment 136687 [details]
Here is a trivial test case

If it were trivial, it wouldn't need to be a zip file (and we could then load
it much more easily).  (You can always use data: URLs for the IFRAME contents. 
See )


15 years ago
Attachment #136687 - Attachment is obsolete: true

Comment 12

15 years ago
Created attachment 136730 [details]
Trivial test case

(Wow, why did no one tell me about data: before..?)

Comment 13

15 years ago
I just had a play with res/html.css.  Removing "inset" from the iframe border
style prevents the bug (but looks horrid).

Comment 14

15 years ago
The problem still exists in FireFox 0.8
I'm working on a commercial software system, in a MS house.  I've been given the
opportunity to, if it's not too much maintenance, change the code such that it
works in both IE and Moz.  Since the main page is done with iframes within
tables, this is obviously a problem.

After looking at the test cases:
The first one is valid, but with the exception of specifying pixels vs.
percentage, I can't work around the bug.
The (related) test case seems to work perfectly, but it has nothing to do with
tables.  Maybe it's related because the frames display properly within another
The trivial test case seems to work OK as well, also has nothing to do with
tables.  The reason I feel this works OK (it does display a little funny) is
because there is no indication to the outer frame of a size for the inner frame,
so it just makes the frame a default size.  Frames are not like tables in that
they will not expand based on the data.  If you change the outer frame to
include height="50%" it diplays better.

If anyone can suggest a workaround, I'd truly appreciate it.

Comment 15

15 years ago
I thought this:
was another test case - but it only uses forms and tables, not frames.  Still,
it renders okay in IE6 but not in Gecko/20040307 Firefox/0.8.0+.  Is it related?

Comment 16

15 years ago
Another test can be found on
Look at left banner under topic "Reklama", which is iframe with width=100%
inside table, but the width is greater then column width

Comment 17

15 years ago
It remerged in 1.7RC1 as far as i can tell.
Does what it should do in Firefox0.8 and moz1.6,
but in 1.7RC1 the iframe's right border is set to the page border it seems.
Flags: blocking1.7+

Comment 18

15 years ago
please do not set flags if you don't know how. thanks.
Flags: blocking1.7+

Comment 19

15 years ago
(In reply to comment #18)
> please do not set flags if you don't know how. thanks.

Would it be ok to set it to "blocking1.8a?" to indicate a request that it be
fixed in 1.8?  I really need this fixed, and a target milestone of "future"
doesn't sound like it will happen this year.




15 years ago
Flags: blocking1.8a?


15 years ago
Flags: blocking1.8a? → blocking1.8a-
OK.  This bug, as originally reported, is worksforme.  So are all the testcases
posted in the bug.

Since all comments after comment 6 have nothing to do with this bug, marking
worksforme.  Please file separate bugs for separate issues.
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME


3 months ago
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.