Steps to reproduce:
1. Open WebKit
2. Click on a link to the page that has htaccess authentication
3. Browser prompts for the username and password
4. Evade the prompt by hitting Escape
5. Page remains empty
6. Click on the above-mentioned link again
7. Browser goes to the correct tab but doesn't prompt for a login
Confirmed with a local debug build of WebKit r28711 with Safari 3.0.4 (523.12) on Mac OS X 10.4.11 (9S165).
* STEPS TO REPRODUCE
1. Launch Safari/WebKit.
2. Open a URL with a link to another page that uses basic authentication: http://www.macosforge.org/
3. Command-click (or right-click and select "Open Link in New Tab") the "Login" link in the upper right-hand corner of the page (you may have to scroll to the right).
4. Click on the new tab (which should have an alert icon on it).
5. Hit Escape to dismiss the auth sheet.
6. Try to click on a link on the page, or scroll it.
The image shown on the new tab is simply an image of the first page, but doesn't really do anything. Note that if you hit Command-A to select the entire page, it "disappears".
This is a regression from Safari 2. In Safari 2, the new tab is focused immediately (with a blank page), so that hitting Escape to dismiss the auth sheet will leave you with a blank page. In Safari 3, the auth sheet doesn't drop until you switch to the tab, but hitting Escape will leave the image of the original page. This is very confusing to the user since they expect to be able to scroll the page or click on links!
I think this may be a Safari issue, but I'll leave this bug open for now. If it is a Safari issue, this bug will be closed as RESOLVED/INVALID (since it can't be fixed in WebKit) and will be tracked by the internal Radar bug.
See also Bug 15063.
I suspect you're right that this is the same as 15063. If so, it seems to be a WebKit bug, not a Safari bug -- WebKit is keeping the WebFrameView sized at 0,0 until the first layout, which means there is no NSView that draws (even an opaque background) in the incoming WebView area, so the screen continues to show the bits from the old view in this area.
One way to fix it is might be to make WebView draw an opaque white background when there is zero-sized documentView in the main frame. But a better way would be to somehow ensure that the main WebFrameView is sized to the entire area of the WebView in these cases where no layout has yet occured (or to make sure a layout does occur).
The WebHTMLView being sized 0x0 is a red herring. It's OK for it to be that size. The real issue is the setting of drawsBackground on the NSScrollView.
Same underlying cause as bug 15063.
*** This bug has been marked as a duplicate of 15063 ***