Painting bug in this case with iframe resizing

RESOLVED WORKSFORME

Status

()

Core
Layout: View Rendering
P2
normal
RESOLVED WORKSFORME
8 years ago
8 years ago

People

(Reporter: Martijn Wargers (zombie), Unassigned)

Tracking

({regression, testcase})

Trunk
x86
Linux
regression, testcase
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Created attachment 436814 [details]
testcase

See testcase, you should not see any red after 100ms, but in current trunk builds, there is. I don't see this problem in Firefox3.6.

The iframe content is this:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
</head>
<body>
<svg xmlns="http://www.w3.org/2000/svg" style="display: table-row-group;"></svg>
<svg xmlns="http://www.w3.org/2000/svg" style="display: table-column;"></svg>
<svg xmlns="http://www.w3.org/2000/svg"></svg>
</body>
</html>
Yeah, looks like an invalidation bug.  Blurring the window, e.g., repaints.
blocking2.0: --- → ?
blocking2.0: ? → final+
Priority: -- → P2
I get this regression range
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83c887dff0da&tochange=d6bb0f9e9519

Which is about a month after this bug was reported. So I don't know what is going on.
I now see a flash of red, but it goes away.  Win7, today's nightly.  WFM?
The red stays until I do something that causes an invalidate on Linux at least with latest nightly.
OK, on Windows it's fine for me (D3D10 layers in play).
OS: Windows 7 → Linux
WFM, Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101208 Firefox/4.0b8pre
(Reporter)

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.