194804 - iframe not rendered if two iframes are stacked on top of each other

Status: RESOLVED FIXED

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

Description

[Michael Percy]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211

As you can see form the source in the testcase URL, there are two iframes, one
has a red bg, on with a blue bg. They are stacked on top of each other and
absolutely sized with a height of 50. However, for whatever reason, the 2nd
iframe is not rendered at all (the blue one).

This renders fine in older versions of Mozilla, as well as IE and Konqueror.

Another interesting case is when you take all the tables and just leave the two
iframe tags in the body... it seems to render 100px high but it is still all red.

Reproducible: Always

Steps to Reproduce:
See the testcase URL or make a page with two iframe tags next to each other,
like so:

<iframe src="redpage.html" name=a width=100% height=50 marginwidth=0
 marginheight=0 border=0 frameborder=0 scrolling=auto></iframe>
<iframe src="bluepage.html" name=b width=100% height=50 marginwidth=0
 marginheight=0 border=0 frameborder=0 scrolling=auto></iframe>

Actual Results:  
only the red iframe is rendered

Expected Results:  
render both red and blue iframes

Comment 1

[Michael Percy]

Please note that the testcase URL is http://www.micko.org/phoenix/px_bug.html
for history, in case it is changed. I am also seeing this in recent Phoenix
builds. I am using GTK2/XFT2 builds.

Comment 2

[Michael Percy]

Sorry for the SPAM flood... asking for this bug to be fixed for 1.3 as it is a
regression from 1.2 and it is causing problems for Mozilla users at my place of
employment with a webapp that is unusable without this fix.

Comment 3

[Jesiah S]

I see it also.
I notice that it only takes one table and not two like in the reporters example
to show this bug.  If you take both tables out it renders both IFRAMEs corectly.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030224

Comment 4

[Boris Zbarsky [:bzbarsky]]

The second iframe seems to be getting a computed width of 0....

Is there a minimal testcase (in particular the minimal number of tables needed
to reproduce the bug) for this bug?

Comment 5

[Michael Percy]

I have added two more testcases:

With only one enclosing table: http://www.micko.org/phoenix/px_bug_1_table.html
With no tables: http://www.micko.org/phoenix/px_bug_iframes_only.html

I originally saw this in a recent phoenix build, so that is why I mention
phoenix in the testcases.

Also, re comment 3 by Jesiah, on my machine with the iframes-only testcase it
shows one big 100px-high block, all red. No blue. I don't know if this is a
caching issue or something weird like that but I don't think it is, I think it
is rendering the same URL in both iframes.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: real minimal testcase

This is as stripped as it can go while still showing the bug.  I've changed it
from "100%" widths to "90%" to illustrate the problem more clearly.  To whit,
the first iframe gets 100% of the width, the second one gets 100% of what's
left, so 0 (with the "90%" setting this is very clear).   This issue is covered
by bug 110358.

This is all as long as no wrapping happens, of course; adding the frameborder
lets things wrap for some odd reason and then the sizes are "correct".

Standards mode makes no difference.

I suspect the "regression" is in somewhere in the linebreaking logic....

Comment 7

[Michael Lefevre]

confirming (with 2003022408/trunk/win2k)

Comment 8

[Michael Percy]

Nominating for Mozilla 1.4 beta. We should purge the codebase of layout bugs
such as this one for the stable long-term branch.

Also removing URL, as I upgraded my server and lost those files. Please use the
test case attached to this bug. Also updating dependency info.

Comment 9

[Michael Percy]

Sorry for spam, forgot to set the 1.4b? flag

Comment 10

[Boris Zbarsky [:bzbarsky]]

1.4b froze today.  Any real bugfixing for 1.4b needed to start a month or more ago.

Just injecting reality....

Comment 11

[Boris Zbarsky [:bzbarsky]]

hmm... fixing bug 97695 did NOT fix this bug....

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 232754