Open
Bug 230863
Opened 21 years ago
Updated 2 years ago
overflow does not apply to IMG when SRC is broken
Categories
(Core :: Layout, enhancement)
Core
Layout
Tracking
()
NEW
People
(Reporter: annevk, Unassigned)
References
Details
(Keywords: css2, helpwanted, testcase)
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:
Reporter | ||
Updated•21 years ago
|
Comment 1•21 years ago
|
||
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
Reporter | ||
Comment 2•21 years ago
|
||
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•21 years ago
|
||
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. ;)
Reporter | ||
Updated•21 years ago
|
Severity: normal → enhancement
Reporter | ||
Updated•21 years ago
|
QA Contact: core.layout.misc-code → ian
Reporter | ||
Comment 4•20 years ago
|
||
Removing the dependecy on bug 97283, since it has nothing to do with this bug.
No longer depends on: 97283
Keywords: helpwanted
Comment 5•19 years ago
|
||
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•19 years ago
|
||
Anne, would you mark this bug WORKSFORME and file a new bug for the scrolling issue?
Comment 7•15 years ago
|
||
This bug should be closed, and a new bug should be filled about the img scrolling
issue.
Updated•15 years ago
|
QA Contact: ian → layout.misc-code
Updated•6 years ago
|
Product: Core → Core Graveyard
Assignee | ||
Updated•6 years ago
|
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•