301 bytes, text/html
302 bytes, text/html
2.89 KB, patch
|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.
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.
Not a frames issue -- testcase with images coming up.
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>).
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 on attachment 136666 [details] [diff] [review] Partial patch r+sr=dbaron. sorry for the delay
Checked in for 1.7a. No worries about the delay; I had no tree anyway. ;)