Summary: Switching from one tab to a newly created tab that has not gotten beyond a certain stage of loading leaves behind the image of the first tab. Forcing redraw may clear the old image. Steps to reproduce: 1) Open any page in a first tab. 2) Create a new empty tab. 3) In the empty tab, type a URL that takes long to start loading (one way to fake this is to run "nc -l 9999" and go to <http://127.0.0.1:9999/>) and press Return. 4) Use the keyboard to switch to the first tab and then back to the new tab. Expected results: When switching to the new tab in step 4, it should display a blank page. Actual results: When switching to the new tab in step 4, it displayed the contents of the first tab. Regression: Regressed between r25065 and TOT. My guess is <http://trac.webkit.org/projects/webkit/changeset/25151>.
I've seen this on Windows too.
Another way to reproduce (only tested on XP) is to set "New Window Opens With" preference to "Empty Page". When Safari is started the "Empty Page" does not get painted, so windows behind Safari bleed through. Dragging windows across the "Empty Page" show it is not getting painted.
(In reply to comment #2) > Another way to reproduce (only tested on XP) is to set "New Window Opens With" > preference to "Empty Page". When Safari is started the "Empty Page" does not > get painted, so windows behind Safari bleed through. Dragging windows across > the "Empty Page" show it is not getting painted. I believe this is <rdar://problem/5424801>, fixed in <http://trac.webkit.org/projects/webkit/changeset/25270>.
(In reply to comment #3) Confirmed "Empty Page" now paints on XP on r25279.
Marking resolved per Comment #4.
(In reply to comment #5) > Marking resolved per Comment #4. What's resolved is the Windows variant of the bug, described in comment #2. The original bug described in comment #0 is still reproducible on Mac.
<rdar://problem/5452227>
Some updated info from the radar: This regressed with the first change in <http://trac.webkit.org/projects/webkit/changeset/25151/trunk/WebCore/loader/FrameLoader.cpp> The problem is that the WebHTMLView has no size (0,0) because there hasn't been any layout that forces a size. Manually resizing cures the problem because it forces a layout via an inLiveResize check in [WebDynamicScrollBarsView updateScrollers].
This sounds a lot like Bug 16417.
Created attachment 25003 [details] patch
*** Bug 16417 has been marked as a duplicate of this bug. ***
Comment on attachment 25003 [details] patch Most excellent.
http://trac.webkit.org/changeset/38245