parent div is not painted as an visible element, if there is no border or content at the last element

RESOLVED WORKSFORME

Status

()

Core
Layout: Floats
RESOLVED WORKSFORME
14 years ago
13 years ago

People

(Reporter: arny, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916

I've added some JS to see the odd rendering.
I think the element should be rendered, even if there is no border or content in
the last element(just like other browsers).
Not sure if this is just a painting bug or maybe more. You tell me.

Reproducible: Always

Steps to Reproduce:
1.click on <add string>
2.refresh your browsers display (by dragging something else above etc)
3.click on <remove string>

Actual Results:  
bad rendering

Expected Results:  
good rendering

Comment 1

14 years ago
The height of the outer div is not affected by the floating elements inside
according to the spec:
http://www.w3.org/TR/CSS21/visudet.html#q19

I'm not sure to understand why adding a border affects the height of the outer
block though, it seems the "clear: right" style is responsible for that because
once removed the height is zero, with a border or not.

Comment 2

14 years ago
Created attachment 132019 [details]
Simplified testcase

Simplified testcase

Comment 3

14 years ago
Created attachment 132020 [details]
Simplified testcase
Attachment #132019 - Attachment is obsolete: true

Updated

14 years ago
Component: Layout: View Rendering → Layout: Floats
Hardware: PC → All
clear:right puts a top margin on the thing being cleared that's big enough to
avoid the float.  But if you have no border on the outer div, this margin
collapses with the outer div's top margin, giving it a height of 0.  This seems
to be correct per what CSS 2.1 says about clear and margin collapsing...
Assignee: roc → float

Comment 5

14 years ago
This bug is about redrawing the background. If you use the DOM Inspector you can
see that while the top (main) div is colapsed, the background remains blue, when
it should be transparent. If you drag another window over it the background redraws.
Follow the steps in the original report to reproduce this effect.
I've also seen this happen with embedded content that does not fill the object
window, such as a plugin - you would expect the body background but instead it's
transparent.
(Reporter)

Comment 6

14 years ago
I'd say there are two bugs.
One at that odd floating behavior and that one is leading to another bug of bad
painting.
> the background remains blue, when it should be transparent.

This part I'm not seeing with this morning's Linux build.  Is it windows-only?

And it's not that the background should be transparent; it's just that it should
be painted over an area 0px tall.

Comment 8

14 years ago
There is no reason for the background to be transparent since the color is never
changed. As pointed by Boris the surface is zero, so there is nothing to see. 

It seems to be a similar margin issue as detailed in Bug 204831.
Depends on: 204831

Comment 9

14 years ago
Created attachment 132212 [details]
Shows background artifact where there is no element.

The description to this bug is misleading. But this image shows what I am
seeing as a bug.
So... is the bug really OS:ALL then?  I can't reproduce that redraw issue on
Linux, and there are a few existing bugs of that sort that are all Windows-only...

Updated

13 years ago
Keywords: testcase
The attached testcase works for me.  The URL does not seem to match the
attached image, nor the Steps To Reproduce in comment 0...
Keywords: testcase

Comment 12

13 years ago
Comment on attachment 132212 [details]
Shows background artifact where there is no element.

Testcase has changed, image no longer matches testcase.
Attachment #132212 - Attachment is obsolete: true
Keywords: qawanted
Bug occurs in 2004-11-25-06 trunk Linux.
Bug does NOT occur in 2004-11-26-06 trunk Linux.

I'm pretty sure roc's work on clearance fixed this bug, in bug 209694.

If the reported "bad painting" problem still occurs (comment 6), then please
file a new bug on that (include a URL or testcase), thanks.

-> WORKSFORME
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Depends on: 209694
Keywords: qawanted → testcase
Resolution: --- → WORKSFORME

Comment 14

13 years ago
I will have to make a new testcase for bad painting and file a new bug on it. I
want to test it on several elements and platforms first.
Referring to my Comment 5
You need to log in before you can comment on or make changes to this bug.