323291 - Painting bug with absolute positioned testcase

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Martijn Wargers (dead)]

See upcoming testcase, you should only see two 20px by 20px boxes, one red and one green. In current trunk builds though, the red one stays much larger.
It is a regression, it doesn't happen in Mozilla1.7 builds (Ria, could you find the regression date?)

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Ria Klaassen (not reading all bugmail)]

Between 20-May-2004:14 and 22-May-2004:09 

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-05-20+13%3A00%3A00&maxdate=2004-05-22+09%3A00%3A00&cvsroot=%2Fcvsroot

Comment 3

[Martijn Wargers (dead)]

In that case, I think this is a regression from bug 243882.

Comment 4

[José Jeria]

The big red box changes to 20x20px if you resize the window. Also, parts of the red box will dissappear if  you drag another application above it.

Comment 5

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

Attachment: fix

The problem is that we were relying on resizing the view to invalidate the area covered by the frame size change (see the comment deleted in this patch), but that doesn't work when overflowing content means the view size doesn't change even though the frame size did. So this patch adds code to invalidate the difference between the old and new areas, currently conditional on the frame not moving, since if it moves the view system will invalidate everything.

After the reflow branch lands, I really need to rethink the way we invalidate during reflow. We currently have an inconsistent mess, and I think it could be much simpler.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 208608 [details] [diff] [review]
fix

r+sr=bzbarsky; let's get that followup bug filed and marked [reflow-refactor] and mention this code in it, ok?

Comment 7

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

checked in. Filed bug 323574 about the general problems.

Comment 8

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

oops, this is actually fixed.

Comment 9

[Steve England [:stevee]]

When loading the testcase the red box starts off at the (incorrect) huge size for a blink-of-an-eye before being redrawn at the correct size. Is this expected behaviour? (I just wonder in case bugs about flickering whilst webpages loading get filed due to this)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Testcase says:

window.onload=function(){
  setTimeout(doe,10);
}

Onload fires after initial layout and paint.

Comment 11

[Worcester12345]

(In reply to comment #9)
> When loading the testcase the red box starts off at the (incorrect) huge size
> for a blink-of-an-eye before being redrawn at the correct size. Is this
> expected behaviour? (I just wonder in case bugs about flickering whilst
> webpages loading get filed due to this)
> 

In branch, the red one stays large while the green one stays small.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060117 Firefox/1.5 ID:2006011703

Comment 12

[Martijn Wargers (dead)]

(In reply to comment #11)
> In branch, the red one stays large while the green one stays small.
That's because it is fixed on trunk, not on branch.

Comment 13

[Worcester12345]

(In reply to comment #12)
> (In reply to comment #11)
> > In branch, the red one stays large while the green one stays small.
> That's because it is fixed on trunk, not on branch.
> 

Which begs the question of whether it should be reopened for Version: ALL

Comment 14

[Boris Zbarsky [:bzbarsky]]

> Which begs the question of whether it should be reopened for Version: ALL

No, it doesn't.  Please go read up on the difference between trunk and branch, ok?