Last Comment Bug 226954 - [FIXr]doesn't show the 'contents' frame
: [FIXr]doesn't show the 'contents' frame
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: P2 normal (vote)
: mozilla1.7alpha
Assigned To: Boris Zbarsky [:bz]
: Hixie (not reading bugmail)
Mentors:
http://arriba.steltenpower.com/iframe...
Depends on: 97695
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-27 13:51 PST by mozilla
Modified: 2004-01-05 17:39 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase 1 -- The mozilla banner should be invisible (301 bytes, text/html)
2003-12-02 08:37 PST, Boris Zbarsky [:bz]
no flags Details
Testcase 2 -- The mozilla banner should be invisible (302 bytes, text/html)
2003-12-02 08:37 PST, Boris Zbarsky [:bz]
no flags Details
Partial patch (2.89 KB, patch)
2003-12-02 08:41 PST, Boris Zbarsky [:bz]
dbaron: review+
dbaron: superreview+
Details | Diff | Splinter Review

Description mozilla 2003-11-27 13:51:42 PST
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 dolphinling 2003-11-27 14:50:53 PST
The Iframes have z-indexes of 1 and 2... didn't we have a bug with positive
z-indexes? Has that been fixed?
Comment 2 Boris Zbarsky [:bz] 2003-12-01 22:13:50 PST
This has nothing to do with the z-indices... the "contents" frame has:

  position: relative; top: -100%

which positions it completely outside the viewport.
Comment 3 Boris Zbarsky [:bz] 2003-12-01 22:27:01 PST
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.
Comment 4 Boris Zbarsky [:bz] 2003-12-02 08:33:25 PST
Not a frames issue -- testcase with images coming up.
Comment 5 Boris Zbarsky [:bz] 2003-12-02 08:37:19 PST
Created attachment 136663 [details]
Testcase 1 -- The mozilla banner should be invisible
Comment 6 Boris Zbarsky [:bz] 2003-12-02 08:37:58 PST
Created attachment 136665 [details]
Testcase 2 -- The mozilla banner should be invisible
Comment 7 Boris Zbarsky [:bz] 2003-12-02 08:41:02 PST
Created attachment 136666 [details] [diff] [review]
Partial patch
Comment 8 Boris Zbarsky [:bz] 2003-12-02 08:42:48 PST
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?
Comment 9 mozilla 2003-12-02 16:56:58 PST
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.
Comment 10 Boris Zbarsky [:bz] 2003-12-02 17:05:32 PST
> 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>).
Comment 11 Boris Zbarsky [:bz] 2003-12-03 00:10:07 PST
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...
Comment 12 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2004-01-01 09:24:18 PST
Comment on attachment 136666 [details] [diff] [review]
Partial patch

r+sr=dbaron.  sorry for the delay
Comment 13 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2004-01-01 09:25:16 PST
->bz
Comment 14 Boris Zbarsky [:bz] 2004-01-05 17:38:46 PST
Checked in for 1.7a.  No worries about the delay; I had no tree anyway.  ;)

Note You need to log in before you can comment on or make changes to this bug.