Bug 25269
| Summary: | REGRESSION: fast/repaint/fixed.html paints too much | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ddkilzer, hyatt, jchaffraix, mitz, simon.fraser |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.5 | ||
| Bug Depends on: | |||
| Bug Blocks: | 25602 | ||
Eric Seidel (no email)
run-webkit-tests -p fast/repaint/fixed.html
shows the failure.
This is a regression, so technically p1, but I feel bad marking it such. ;)
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
mitz
<rdar://problem/6802446>
Simon Fraser (smfr)
The repaint that does not cover the green square is coming out of RenderLayer::updateLayerPositions(), painting m_repaintRect which has the pre-scroll location, and happens via the call to layout() from externalRepresentation().
Repaints of fixed position elements when the page has not just scrolled are not too large, so we're not over-painting in the common case.
Julien Chaffraix
I looked at the different outputs of fast/repaint/fixed.html and they look fine on Chromium and Mac. Gtk has a bad image checked-in as it does not seem to implement createBitmapContextFromWebView properly.