Closed Bug 244017 Opened 17 years ago Closed 17 years ago

Parts of the surrounding div not painted/drawed with large floating div

Categories

(Core :: Web Painting, defect, P2)

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: roc)

References

()

Details

(Keywords: fixed-aviary1.0, fixed1.7, testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040515 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040515 Firefox/0.8.0+

See upcoming testcase.
Also discussed here:
http://forums.mozillazine.org/viewtopic.php?t=77420&sid=4022e3499b6d2ad0f358040adf273378

When you have a large  div (float:left) with style="float:left" and afterwards a
<br clear="all"> (or something similar), you'll get a chance that the surrouring
div's background-color/border/etc is not getting painted correctly.
After scrolling the viewport, the "missing" parts which were not painted get
painted afterwards.

The chance to experience the bug is higher when there is quite a large portion
of content in the floated div, so that's why the testcase contains quite some
dummy text.
If you don't experience the bug directly, try a shift-reload.

A css declaration of overflow:hidden; on the surrounding div seems to fix the
bug, by the way.

Reproducible: Sometimes
Steps to Reproduce:
1. See testcase
2.
3.

Actual Results:  
I did see a red background color

Expected Results:  
You should see only a green background color
I can reproduce this on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a)
Gecko/20040427 MultiZilla/1.6.4.0b (trunk build)
confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
This bug is quite long standing, and affects many modern sites out there, I hope
it can be resolved quick, it needs to, as it stops me, and many others, from
creating the design we want :-( What are we expected to do no? go back to
tables? avoid floats all together? or have white backgrounds on every page? This
bug really needs to be resolved, , I see this as one of the most important bugs
in mozilla. just about every redesign I try to do to my site... and the bug
already pops up... yet again!

here's some of the sites that get affected by this bug:

http://www.scriptygoddess.com/
http://www.simplebits.com/     (especially services,notebook page)
http://www.opera.com/          (especially download page)
http://www.7nights.com/asterisk/archive.php
http://jls.geek.nz/pages/gallery/?album=%2FComputers%2FP4%202000&

even Zeldman's own site does it! the guy that wrote designing with web standards:

http://www.zeldman.com/dwws/   (the green sidebar often does not paint)

and my own site used to do it, until I had to write a mozilla hack on two pages
to avoid it...

http://blair.wise.net.nz/~robvdl/galler.php (my own site, I had to write
workarounds to fix this!)

This bug is affected by the time it takes for the page to load, and also on how
much content is in the div, before the clearing div. if it doesn't happen first
time, refresh a couple of times - all sites above WILL do it! it might appear
quite random...
Is this Windows only?
(In reply to comment #5)
> Is this Windows only?

I do not not, sorry, Windows is the only platform I have accsess too, but it is
quitie possible
*** Bug 238400 has been marked as a duplicate of this bug. ***
I can reproduce this on GTK with PAINT_SEPARATELY.
Okay. The bug is in nsBlockFrame::ReflowLine or thereabouts. 

    // We expect blocks to damage any area inside their bounds that is
    // dirty; however, if the frame changes size or position then we
    // need to do some repainting
    if (aDamageDirtyArea) {
      nsRect lineCombinedArea(aLine->GetCombinedArea());
      if ((oldCombinedArea.x != lineCombinedArea.x) ||
          (oldCombinedArea.y != lineCombinedArea.y)) {

The comment is correct; generally speaking we expect frames to paint any area
inside their bounds that is dirty, but parents are responsible for painting
changes in the child's bounds. But this code *actually* paints changes in the
child's combinedArea (==overflowArea)! In this testcase the "surrounding" DIV's
bounds are changing but its combinedArea isn't (much). So we don't invalidate
where we need to.

I need to think about what to do here. If we change this code to paint only the
difference in frame bounds then we might hork something. But I think it's the
right thing to do.
Attached patch hackSplinter Review
This works. I will start a discussion on .layout about what to do about this
bug for real.
Comment on attachment 151837 [details] [diff] [review]
hack

I think we should check this in for now, because it fixes probably a wide class
of invalidation bugs.
Attachment #151837 - Flags: superreview?(dbaron)
Attachment #151837 - Flags: review?(dbaron)
Attachment #151837 - Flags: superreview?(dbaron)
Attachment #151837 - Flags: superreview+
Attachment #151837 - Flags: review?(dbaron)
Attachment #151837 - Flags: review+
checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
*** Bug 210156 has been marked as a duplicate of this bug. ***
*** Bug 210156 has been marked as a duplicate of this bug. ***
*** Bug 250761 has been marked as a duplicate of this bug. ***
This bug is already fixed and should be backported to aviary1.0. It's an
importantly fix which should come with FF1.0 cause a lot of websites are using
floating divs.

Asking for blocking aviary1.0RC1.
Flags: blocking-aviary1.0RC1?
Whiteboard: needed-aviary1.0
this being a temporary hack, and not present in 1.7, I don't think we should
backport this yet, otherwise we won't have consistent behaviour with Mozilla
1.7, which we should have as much as possible.

If this goes into the 1.7 branch, we should include it on the aviary branch as well.
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1-
Whiteboard: needed-aviary1.0
This is not a temporary hack. It is a permanent hack :-)
Comment on attachment 151837 [details] [diff] [review]
hack

this is quite simple and safe and fixes some ugly bugs.
Attachment #151837 - Flags: approval1.7.2?
Comment on attachment 151837 [details] [diff] [review]
hack

a=mkaply for 1.7.2
Attachment #151837 - Flags: approval1.7.2? → approval1.7.2+
I love permanent hacks. :)
Flags: blocking-aviary1.0RC1- → blocking-aviary1.0RC1+
Whiteboard: needed-aviary1.0
*** Bug 216384 has been marked as a duplicate of this bug. ***
checked in on 1.7 branch.
Flags: blocking1.7.2?
Keywords: fixed1.7
Someone please make sure this lands on the Aviary branch.
I'll do that tomorrow, I _should_ have a large chunk of time to do some branch
merging stuff.
Keywords: fixed-aviary1.0
Whiteboard: needed-aviary1.0
*** Bug 259223 has been marked as a duplicate of this bug. ***
Verified FIXED with build 2004-11-12-04 on Windows XP, Seamonkey trunk.
Status: RESOLVED → VERIFIED
Depends on: 451332
With the fix on bug 471365 we can handle invalidation issues now. Asking for in-testsuite based on bug 451332 comment 8.
Flags: in-testsuite?
I have looked into creating an invalidate reftest for this problem, but unfortunately I have been completely unable to reproduce it.  I've tried using the following builds and OS's:

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a) Gecko/20040516 Firefox/0.8.0+ on Windows 98 SE

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7) Gecko/20040602 Firefox/0.8.0+ on Windows XP Pro

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040514 Firefox/0.8.0+ on Windows 2000 Pro

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040302 Firefox/0.8.0+ on Windows 2000 Pro

Is it possible the bug is sensitive to CPU speed, or is specific to some particular OS patch level?  If anyone else can reproduce this bug, please let me know how you were able to do it, otherwise I recommend removing the in-testsuite? flag.
I'm removing the dependency on 451332 since I cannot reproduce this bug.
No longer depends on: 451332
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.