Closed Bug 226954 Opened 21 years ago Closed 21 years ago

[FIXr]doesn't show the 'contents' frame

Categories

(Core :: Layout: Block and Inline, defect, P2)

Product:
Core
Component:
Layout: Block and Inline
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7alpha

People

(Reporter: mozilla, Assigned: bzbarsky)

References

(
URL
)

Details

Attachments

(3 files)

Testcase 1 -- The mozilla banner should be invisible
301 bytes, text/html
Details
Testcase 2 -- The mozilla banner should be invisible
302 bytes, text/html
Details
Partial patch
2.89 KB, patch
dbaron
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031117 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031117 There should be 3 'layers of paint': the page itself, which is just blue on top of that the 'contents' iframe on top of that the menu iframe The iframes are partly transparent. In IE it renders right, in Mozilla it doesn't. Usually it's the other way around. Mozilla rules Reproducible: Always Steps to Reproduce: 1. 2. 3.
The Iframes have z-indexes of 1 and 2... didn't we have a bug with positive z-indexes? Has that been fixed?
This has nothing to do with the z-indices... the "contents" frame has: position: relative; top: -100% which positions it completely outside the viewport.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
Actually, reopening. It looks like "top: -100%" in fact does absolutely nothing. That seems wrong. At a guess, we need to set aContainingBlockHeight to the cbrs height in InitConstraints _before_ we call ComputeRelativeOffsets.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Not a frames issue -- testcase with images coming up.
Assignee: frame → block-and-inline
Status: UNCONFIRMED → NEW
Component: Layout: HTML Frames → Layout: Block & Inline
Ever confirmed: true
OS: Windows XP → All
QA Contact: ian
Hardware: PC → All
Attached patch Partial patch — — Splinter Review
That patch fixes the site and testcase 1. It does NOT fix testcase 2. For some reason aContainingBlockHeight is auto there, even though the <body> has a style height specified... I could hack this code to handle that, probably, but it just seems wrong. Any ideas what's up?
somebody says top -100% is nonsense, but i'd like an explanation on that. I think it's correct and try to explain why: The 'first' iframe is 100% of it's container's (the body) height, which means everything that comes after will start exactly out of view. But if you position the '2nd' relative to the first with a negative translation that is exactly as big as the height of the first, the tops of the both iframes will be exactly at the same spot. In Internet Explorer it does what i intended, which usually Mozilla does a better job at.
> somebody says top -100% is nonsense, No one said that... Note that the final patch here may NOT end up fixing your site, since you are depending on a quirk in percentage resolution which we may decide should not apply here (100% of an auto body height as in your case is auto, so the top offset should really be auto -- that's why the testcases I posted use a fixed height for the <body>).
Depends on: 97695
Comment on attachment 136666 [details] [diff] [review] Partial patch OK, the issue with the second testcase is resolved by the patch in bug 97695. Looks like line layout is just passing us a bogus CB height here...
Attachment #136666 - Flags: superreview?
Attachment #136666 - Flags: review?
Attachment #136666 - Flags: superreview?(dbaron)
Attachment #136666 - Flags: superreview?
Attachment #136666 - Flags: review?(dbaron)
Attachment #136666 - Flags: review?
Comment on attachment 136666 [details] [diff] [review] Partial patch r+sr=dbaron. sorry for the delay
Attachment #136666 - Flags: superreview?(dbaron)
Attachment #136666 - Flags: superreview+
Attachment #136666 - Flags: review?(dbaron)
Attachment #136666 - Flags: review+
->bz
Assignee: core.layout.block-and-inline → bz-vacation
Summary: doesn't show the 'contents' frame → [FIXr]doesn't show the 'contents' frame
Priority: -- → P2
Target Milestone: --- → mozilla1.7alpha
Checked in for 1.7a. No worries about the delay; I had no tree anyway. ;)
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: