Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in mozilla1.7alpha

Status

()

Core
Layout: Block and Inline
P2
normal
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: mozilla, Assigned: bz)

Tracking

Trunk
mozilla1.7alpha
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
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.

Comment 1

14 years ago
The Iframes have z-indexes of 1 and 2... didn't we have a bug with positive
z-indexes? Has that been fixed?
(Assignee)

Comment 2

14 years ago
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
Last Resolved: 14 years ago
Resolution: --- → INVALID
(Assignee)

Comment 3

14 years ago
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 → ---
(Assignee)

Comment 4

14 years ago
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
(Assignee)

Comment 5

14 years ago
Created attachment 136663 [details]
Testcase 1 -- The mozilla banner should be invisible
(Assignee)

Comment 6

14 years ago
Created attachment 136665 [details]
Testcase 2 -- The mozilla banner should be invisible
(Assignee)

Comment 7

14 years ago
Created attachment 136666 [details] [diff] [review]
Partial patch
(Assignee)

Comment 8

14 years ago
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?
(Reporter)

Comment 9

14 years ago
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.
(Assignee)

Comment 10

14 years ago
> 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>).
(Assignee)

Updated

14 years ago
Depends on: 97695
(Assignee)

Comment 11

14 years ago
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?
(Assignee)

Updated

14 years ago
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
(Assignee)

Updated

14 years ago
Priority: -- → P2
Target Milestone: --- → mozilla1.7alpha
(Assignee)

Comment 14

14 years ago
Checked in for 1.7a.  No worries about the delay; I had no tree anyway.  ;)
(Assignee)

Updated

14 years ago
Status: NEW → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.