Summary: Clicking "Back" button after viewing a PDF in the browser sometimes causes the web page to be redrawn differently. Steps to Reproduce: This is easiest to see on Google search pages where a blue bar above the "Results MM - NN of about Y,YYY,YYY for <search criteria> (D.DD seconds)" text appears much larger than it should. 1. Search for some PDF documents in Google. http://www.google.com/search?q=filetype:pdf+pdf&hl=en&lr=&safe=off&start=10&sa=N 2. Click on a PDF to view. PDFs larger than 1 MB seem to work best. 3. Wait for PDF to load, then click "Back" button. 4. If the web page draws correctly, click the "Forward" button, then the "Back" button. Repeat as needed until it happens. Expected Results: The web page should look exactly the same when going back as it looked before clicking on the PDF. Actual Results: The web page sometimes redraws incorrectly. Regression: Not tested with a production release of Safari yet.
This is a regression from Safari 2.0.3 (417.8) on 10.4.4. Bumping priority to P1. Adding Regression keyword and updating Summary. > 2. Click on a PDF to view. PDFs larger than 1 MB seem to work best. This is not true. A PDF of any size will work. It seems that you must click on the PDF, click "Back", click "Forward", then click "Back" once again to reproduce the problem. (This works every time I've tried). Bug 7085 may be related since it involves PDFs and the "Back" button.
I was able to reproduce this bug with WebKit nightly build r12596.
Created attachment 6338 [details] Test case Here's how to reproduce the bug: 1. Open test case attachment in Safari. 2. Click on PDF link. Wait for PDF to fully load. 3. Click "Back" button once. 4. Click "Forward button once. 5. Click "Back" button once. The thin, blue line above the PDF link is now much wider.
After careful inspect of Google's results page, it's only this one element that is not being redrawn properly when going back from viewing a PDF file. (Note that once/if Bug 3527 lands, the same thing happens with PostScript and EPS files.)
I did more experiments. This same bug happens even when the link is to a standalone image rather than a PDF. The link I used was: http://www.google.com/intl/en/images/logo.gif Also, the image itself still has a width and height of 1. It's the table cell that ends up with too large a height. And it's definitely a back/forward cache bug. Turning the back/forward cache off with the Debug menu makes the bug go away.
The bug is that when we go back, we're in strict mode. In strict mode, the height of the cell is based on the ascent and descent of the text even though there are no actual characters in the cell.
This is clearly a bug in the way the back/forward caching works. The bug doesn't happen if the caching is off. I think the essence of the problem is that the document is still installed in the WebFrame when displaying non-HTML content, so when we call "end" it thinks it's just started writing into a new document, and it ends up marking the old document strict. The best fix is perhaps to get the document out of the frame.
<rdar://problem/4483851>
Created attachment 7352 [details] a fix
Verified fixed on locally-built r13568. (Fix committed as r13530.)
Comment on attachment 7352 [details] a fix The change for this bug has been rolled out since it broke Spinneret and it's easy to roll back in with proper testing later.
Testing with ToT (r15230) shows that this has since been fixed. It appears that r14211, the fix for bug 8626, provided the fix. I would invite some else to confirm and close this bug if they agree with my assessment.
I think you're right. That other bug fix did fix this one!