| Summary: | REGRESSION: Image of original web page is left on new tab when basic/digest authentication dialog is dismissed | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ain Tohvri <ain> |
| Component: | Page Loading | Assignee: | Darin Adler <darin> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | sullivan |
| Priority: | P2 | Keywords: | InRadar, Regression |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac (Intel) | ||
| OS: | OS X 10.4 | ||
| URL: | http://www.macosforge.org/ | ||
|
Description
Ain Tohvri
2007-12-13 00:21:30 PST
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. * RESULTS 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". * REGRESSION 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. 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. |