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

Status: RESOLVED WORKSFORME

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

Description

[Randell Jesup [:jesup] (needinfo me)]

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
     cellpadding=0
-->

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: testcase

Minimal testcase

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Same problem with trunk.

Once we fix this, we may want to add it to the regression tests

Comment 3

[Kevin McCluskey (gone)]

Reassigning to John.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

John - any progress on this?  have you looked at the testcase?

Comment 5

[Kevin McCluskey (gone)]

Bulk moving P1-P5 un-milestoned bugs to future. 

Comment 6

[Markus Hübner]

Is this still valid?

Comment 7

[Jeremy Brown]

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

[Jeremy Brown]

Attachment: another (related) test case

Comment 9

[Peter L Jones]

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

http://www.simlogical.com/

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

[Peter L Jones]

Attachment: Here is a trivial test case

Adding 'style="margin: 0pt"' to the body tag triggers the error.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 http://software.hixie.ch/utilities/cgi/data/data )

Comment 12

[Peter L Jones]

Attachment: Trivial test case

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

Comment 13

[Peter L Jones]

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

Comment 14

[Nick K. Aghazarian]

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
element?
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

[Peter L Jones]

I thought this:
http://www.dabs.com/uk/channels/components/
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

[Mike Crash]

Another test can be found on http:www.tvfreak.cz
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

[Willem Voogd]

It remerged in 1.7RC1 as far as i can tell. 
http://www.duijvestein.com
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.

Comment 18

[Asa Dotzler [:asa]]

please do not set flags if you don't know how. thanks.

Comment 19

[Nick K. Aghazarian]

(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.

Thanks,

Nick

Comment 20

[Boris Zbarsky [:bzbarsky]]

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.