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
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.
Created attachment 132020 [details] Simplified testcase
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...
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.
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.
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.
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...
The attached testcase works for me. The URL does not seem to match the attached image, nor the Steps To Reproduce in comment 0...
Comment on attachment 132212 [details] Shows background artifact where there is no element. Testcase has changed, image no longer matches testcase.
13 years ago
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
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