Closed
Bug 217817
Opened 22 years ago
Closed 21 years ago
Sequence of 100% IFRAMEs or IMG causes only the first one to be displayed
Categories
(Core :: Layout: Tables, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: philippe, Unassigned)
References
()
Details
(Keywords: testcase)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 Mozilla Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 Mozilla Firebird/0.6.1+
When using IFRAMEs without no element between them, ie
<IFRAME ...></IFRAME>
<IFRAME ...></IFRAME>
<IFRAME ...></IFRAME>
only the first one is displayed, the other seem to be located just under the
first one and not displayed. Simply adding an element eg <BR> is a workaround.
This is a regression in FB 0.6.1; it is working well with Phoenix 0.5.
Reproducible: Always
Steps to Reproduce:
1. Look at http://home.planetinternet.be/~pbajoit/lebutch/Mozilla/master.htm ,
only 1 IFRAME is visible
2. Look at the HTML, 3 are used,
3. Look at http://home.planetinternet.be/~pbajoit/lebutch/Mozilla/masterOK.htm ,
the 3 IFRAMEs are visible
4. Look at the HTML, the IFRAMEs are separated with <BR>
Actual Results:
Only 1 IFRAME is displayed rather than all (3 in the example)
Expected Results:
Display all IFRAMEs NOT on top of each other.
Reporter | ||
Updated•22 years ago
|
Summary: Sequence of IFRAMEs causes only the first ont to be displayed → Sequence of IFRAMEs causes only the first ont to be displayed
Reporter | ||
Updated•22 years ago
|
Summary: Sequence of IFRAMEs causes only the first ont to be displayed → Sequence of IFRAMEs causes only the first one to be displayed
![]() |
||
Comment 1•22 years ago
|
||
Are all the nested tables necessary to reproduce this bug? Or is it
reproducible with fewer levels of nesting, possibly without tables at all?
Seeing this in 1.5b SeaMonkey, so over to layout.
Assignee: blake → block-and-inline
Component: General → Layout: Block & Inline
Product: Firebird → Browser
QA Contact: asa → ian
Version: unspecified → Trunk
Reporter | ||
Comment 2•22 years ago
|
||
Actually the problems is related to TABLEs.
BODY containing just IFRAMEs works well.
![]() |
||
Comment 3•22 years ago
|
||
Right, but there are several levels of table nesting in the testcase. Are they
all needed?
Put another way, how much HTML can you remove and still have the problem show up?
Reporter | ||
Comment 4•22 years ago
|
||
The test case is now better.
A simple TABLE is enough to reproduce.
Accurately, all these conditions are needed:
1. a TD of a TABLE
2. nothing between the IFRAMEs
3. IFRAME attribute FRAMEBORDER="0"
4. IFRAME attribute WIDTH="100%"
Comment 5•22 years ago
|
||
Same problem occurs using <img width=100%> in a table
Comment 6•22 years ago
|
||
Maybe this will be fixed by bug 173277?
-> Layout:Tables
Assignee: block-and-inline → table
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Layout: Block & Inline → Layout: Tables
Depends on: 173277
Ever confirmed: true
Keywords: testcase
OS: Windows 2000 → All
QA Contact: ian → madhur
Summary: Sequence of IFRAMEs causes only the first one to be displayed → Sequence of 100% IFRAMEs or IMG causes only the first one to be displayed
![]() |
||
Comment 7•22 years ago
|
||
Ah, good point... shouldn't we be line-breaking between those iframes/images,
though?
Comment 8•22 years ago
|
||
Yes, we probably should, but I think we have a compatibility hack that makes us
keep <img> space <img> on the same line no matter what...
Not related to bug 173277. I think I see what happens now, there is simply
no space left for the second image once the first has been sized to the full
width of the cell so it will be 100% of zero.
No longer depends on: 173277
Comment 9•22 years ago
|
||
![]() |
||
Comment 10•22 years ago
|
||
Looks like bug 97695, then. We should be sizing as percentage of containing
block, not available space...
Reporter | ||
Comment 11•22 years ago
|
||
Notice that on IFRAMEs
1. with WIDTH="100%"
2. without FRAMEBORDER="0"
the display is correct
Depends on: 97695
![]() |
||
Comment 12•21 years ago
|
||
This is probably dependent on bug 194804 too -- there seems to be an issue with
what tables do
Depends on: 194804
Reporter | ||
Updated•21 years ago
|
![]() |
||
Updated•21 years ago
|
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•