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

Status: VERIFIED FIXED

(Core :: Web Painting, defect, P2)

Description

[Martijn Wargers (dead)]

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

Comment 1

[Martijn Wargers (dead)]

Attachment: Testcase with large floating div

Comment 2

[Raj Bhaskar]

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)

Comment 3

[Bernard Alleysson]

confirming

Comment 4

[Rob van der Linde]

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

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this Windows only?

Comment 6

[Rob van der Linde]

(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

Comment 7

[Robin Monks]

*** Bug 238400 has been marked as a duplicate of this bug. ***

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I can reproduce this on GTK with PAINT_SEPARATELY.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: hack

This works. I will start a discussion on .layout about what to do about this
bug for real.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in.

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

*** Bug 210156 has been marked as a duplicate of this bug. ***

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

*** Bug 210156 has been marked as a duplicate of this bug. ***

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

*** Bug 250761 has been marked as a duplicate of this bug. ***

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 17

[Mike Connor [:mconnor]]

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.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is not a temporary hack. It is a permanent hack :-)

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 151837 [details] [diff] [review]
hack

this is quite simple and safe and fixes some ugly bugs.

Comment 20

[Mike Kaply [:mkaply]]

Comment on attachment 151837 [details] [diff] [review]
hack

a=mkaply for 1.7.2

Comment 21

[Mike Connor [:mconnor]]

I love permanent hacks. :)

Comment 22

[Stephen Donner [:stephend] Not actively reading bugmail]

*** Bug 216384 has been marked as a duplicate of this bug. ***

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in on 1.7 branch.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Someone please make sure this lands on the Aviary branch.

Comment 25

[Mike Connor [:mconnor]]

I'll do that tomorrow, I _should_ have a large chunk of time to do some branch
merging stuff.

Comment 26

[Boris Zbarsky [:bzbarsky]]

*** Bug 259223 has been marked as a duplicate of this bug. ***

Comment 27

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED with build 2004-11-12-04 on Windows XP, Seamonkey trunk.

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+1]]

With the fix on bug 471365 we can handle invalidation issues now. Asking for in-testsuite based on bug 451332 comment 8.

Comment 29

[Jonathan Griffin (:jgriffin)]

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.

Comment 30

[Jonathan Griffin (:jgriffin)]

I'm removing the dependency on 451332 since I cannot reproduce this bug.