Bug 15063 – REGRESSION (r25151): Switching to a tab waiting for first data does not clear the window

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

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>.

[Matt Lilek]

I've seen this on Windows too.

[Darren Collins]

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>.

[Darren Collins]

(In reply to comment #3)

Confirmed "Empty Page" now paints on XP on r25279.

[David Kilzer (:ddkilzer)]

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.

[Adele Peterson]

<rdar://problem/5452227>

[John Sullivan]

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].

[David Kilzer (:ddkilzer)]

This sounds a lot like Bug 16417.

[Darin Adler]

Created attachment 25003 [details]
patch

[Darin Adler]

*** Bug 16417 has been marked as a duplicate of this bug. ***

[John Sullivan]

Comment on attachment 25003 [details]
patch

Most excellent.

[Darin Adler]

http://trac.webkit.org/changeset/38245