REGRESSION: parse mode gets set to strict after going back from non-HTML content

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[David Kilzer (:ddkilzer)]

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.

[David Kilzer (:ddkilzer)]

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.

[David Kilzer (:ddkilzer)]

I was able to reproduce this bug with WebKit nightly build r12596.

[David Kilzer (:ddkilzer)]

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.

[David Kilzer (:ddkilzer)]

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

[Darin Adler]

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.

[Darin Adler]

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.

[Darin Adler]

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.

[Alice Liu]

<rdar://problem/4483851>

[Maciej Stachowiak]

Created attachment 7352 [details]
a fix

[David Kilzer (:ddkilzer)]

Verified fixed on locally-built r13568.  (Fix committed as r13530.)

[Dave Hyatt]

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.

[Mark Rowe (bdash)]

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.

[Darin Adler]

I think you're right. That other bug fix did fix this one!