User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040111 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040111 According to CSS21, the 'height', 'width' and 'overflow' property may be applied to block-level, replaced elements . This works for OBJECT, but not for IMG . Besides, there is some strange behavior between offline and online documents .  <http://www.w3.org/TR/CSS21/visudet.html#the-height-property> <http://www.w3.org/TR/CSS21/visudet.html#the-width-property> <http://www.w3.org/TR/CSS21/visufx.html#overflow>  <http://annevankesteren.nl/test/css/p/overflow/replaced-overflow-auto.xhtml> <http://annevankesteren.nl/test/css/p/overflow/replaced-overflow-auto.htm>  <http://www.letselplein.nl/~exemplarisch/css/bugs/number/> Reproducible: Always Steps to Reproduce:
The problem is that nsCSSFrameConstructor::ConstructAlternateFrame just constructs a frame of the appropriate display type instead of going through the normal frame construction codepaths; as a result we end up with a simple blockframe here instead of the expected scrollframe/blockframe combination. As for the online behavior, your server is totally screwed up and returns a 301 redirect for http://annevankesteren.nl/test/css/p/overflow/broken and the redirect is to a valid status 200 HTML page. No 404 involved anywhere. So the <object> doesn't think it's missing any data. It also doesn't know how to handle that data (since there is no type attr and the code is dumb), so it just renders nothing. There's already a bug on the fact that data of unexpected type doesn't lead to alternate rendering for <object>.
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout: Misc Code
OS: Windows XP → All
QA Contact: ian → core.layout.misc-code
Hardware: PC → All
I added 'type="example"' so it is easier to compare. I will contact my host about the 404 issue. I noticed it before, but I wasn't sure it was incorrect behavior.
Well, it's not _incorrect_ per se. It's just that expected behavior at the moment (without type="example") would be to render that "404" page in the object. ;)
Removing the dependecy on bug 97283, since it has nothing to do with this bug.
This is WFM with current trunk build. It doesn't work in 2005-09-18 trunk build, it works in 2005-09-20 trunk build. Probably fixed by bug 11011. However scrolling is pretty much borked for both <object> (bad) as well as <img>. This seems an older regression. It does work in Mozilla1.7, but not anymore in the 2005-09-18 build.
Anne, would you mark this bug WORKSFORME and file a new bug for the scrolling issue?
This bug should be closed, and a new bug should be filled about the img scrolling issue.
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.