Bug 19425

Summary: Incomplete repaint of position:fixed elements that change size after scroll
Product: WebKit Reporter: Dylan <dylanryan>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Minor CC: mitz, robert
Priority: P4    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
Attachments:
Description Flags
Testcase/reduction
none
Screenshot of fixed position element incorrect rendering after scroll none

Description Dylan 2008-06-06 20:37:03 PDT
Haven't seen this "in the wild", but it affects me on some local HTML files I use.

Basically, after scrolling a page, resizing a positon:fixed element to be smaller than it was does not fully/correctly repaint it the first time it is resized. After it has been resized once, it repaints properly (until another scroll happens...) if you resize it larger and then smaller again. That said, scrolling while it is repainted poorly corrects the current repaint issue.

Note that this is only the case if the first resize makes the element SMALLER - if you make it larger, it repaints fine (again, until another scroll and a shrinking resize)


This happens in shipping Safari 3.1.1 under 10.5.3 (and 10.4.11), as well as the latest nightlies, but it never used to happen to me under Safari 2 in Tiger (forget the version numbers, it has been a while since I ran that, but a page I had that used to work now doesn't). So, it isn't a regression for Safari 3, but Safari 2 used to do it right (Firefox gets it right, too). I don't use the files with this issue in it too often, but I don't think I ever saw that before until today, so this may have regressed at some point in Safari 3's lifetime, I just don't know where or when. 



Test/reduction forthcoming. 


As I said, I have never seen this on the web at large, and it is fairly trivial and not terribly important, but it is a bug...
Comment 1 Dylan 2008-06-06 20:41:39 PDT
Created attachment 21543 [details]
Testcase/reduction

Steps to reproduce: 
1) Scroll page down any amount (the more you scroll, the larger the area that is not properly repainted is, to a point. 2-3 lines is good, or all the way to the bottom)
2) Click the link to resize the positon:fixed div (clicking the link again restores it to its original size)
3) Notice the area that is not properly repainted (usually, a stripe along the bottom of where the full-sized div was is not cleared, though sometimes a stripe along the top or the entire large div remains visible)
Comment 2 Timothy Churchward 2008-11-11 19:04:00 PST
Created attachment 25083 [details]
Screenshot of fixed position element incorrect rendering after scroll

From http://www.panic.com/coda/developer/

to reproduce: scroll down then scroll up again. (I used the mouse wheel on latest WebKit nightly build)
Comment 3 Timothy Churchward 2008-11-11 19:15:57 PST
(In reply to comment #2)

In regards to the coda developer site the behaviour seems to occur inconsistently. The first time I navigate to the coda site scrolling down then up does not cause any problems ... however, if I navigate to another page from that page; then click back; the behaviour will then appear as seen in the above screenshot.
Comment 4 mitz 2008-11-11 19:19:03 PST
(In reply to comment #3)
> (In reply to comment #2)
> 
> In regards to the coda developer site the behaviour seems to occur
> inconsistently. The first time I navigate to the coda site scrolling down then
> up does not cause any problems ... however, if I navigate to another page from
> that page; then click back; the behaviour will then appear as seen in the above
> screenshot.
> 

I think that might be "Failing to reset "slow repaints"/"can blit" mode on the back navigation" which is bug 21256.
Comment 5 Robert Hogan 2013-06-25 11:10:19 PDT
I can no longer reproduce this. Please re-open if you think the bug is still valid.