Painting bug with absolute positioned testcase

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: roc)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
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?)
(Reporter)

Comment 1

12 years ago
Created attachment 208368 [details]
testcase
(Reporter)

Comment 3

12 years ago
In that case, I think this is a regression from bug 243882.
Blocks: 243882

Updated

12 years ago
OS: Windows XP → All
Hardware: PC → All

Comment 4

12 years ago
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.
Created attachment 208608 [details] [diff] [review]
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.
Attachment #208608 - Flags: superreview?(bzbarsky)
Attachment #208608 - Flags: review?(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?
Attachment #208608 - Flags: superreview?(bzbarsky)
Attachment #208608 - Flags: superreview+
Attachment #208608 - Flags: review?(bzbarsky)
Attachment #208608 - Flags: review+
checked in. Filed bug 323574 about the general problems.
oops, this is actually fixed.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
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)
Testcase says:

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

Onload fires after initial layout and paint.

Comment 11

12 years ago
(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
(Reporter)

Comment 12

12 years ago
(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

12 years ago
(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
> 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?
You need to log in before you can comment on or make changes to this bug.