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)

defect

Tracking

()

RESOLVED FIXED
mozilla1.7alpha

People

(Reporter: mozilla, Assigned: bzbarsky)

References

()

Details

Attachments

(3 files)

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 patchSplinter 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 ago21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: