230863 - overflow does not apply to IMG when SRC is broken

Status: NEW

(Core :: Layout, enhancement)

Description

[Anne (:annevk)]

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 [1]. This works for OBJECT, but not for IMG
[2]. Besides, there is some strange behavior between offline and online
documents [3].

[1]
<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>

[2]
<http://annevankesteren.nl/test/css/p/overflow/replaced-overflow-auto.xhtml>
<http://annevankesteren.nl/test/css/p/overflow/replaced-overflow-auto.htm>

[3]
<http://www.letselplein.nl/~exemplarisch/css/bugs/number/>

Reproducible: Always

Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

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>.

Comment 2

[Anne (:annevk)]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.  ;)

Comment 4

[Anne (:annevk)]

Removing the dependecy on bug 97283, since it has nothing to do with this bug.

Comment 5

[Martijn Wargers (dead)]

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.

Comment 6

[Martijn Wargers (dead)]

Anne, would you mark this bug WORKSFORME and file a new bug for the scrolling issue?

Comment 7

[Anders G. Jørgensen]

This bug should be closed, and a new bug should be filled about the img scrolling
issue.