Bug 7102 - REGRESSION: parse mode gets set to strict after going back from non-HTML content
Summary: REGRESSION: parse mode gets set to strict after going back from non-HTML content
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Maciej Stachowiak
Keywords: HasReduction, InRadar, Regression
Depends on:
Reported: 2006-02-06 06:43 PST by David Kilzer (:ddkilzer)
Modified: 2006-07-10 22:00 PDT (History)
4 users (show)

See Also:

Test case (230 bytes, text/html)
2006-02-07 20:41 PST, David Kilzer (:ddkilzer)
no flags Details
a fix (3.36 KB, patch)
2006-03-28 01:40 PST, Maciej Stachowiak
hyatt: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Kilzer (:ddkilzer) 2006-02-06 06:43:15 PST

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.


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.


Not tested with a production release of Safari yet.
Comment 1 David Kilzer (:ddkilzer) 2006-02-06 06:57:13 PST
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.
Comment 2 David Kilzer (:ddkilzer) 2006-02-06 07:00:42 PST
I was able to reproduce this bug with WebKit nightly build r12596.
Comment 3 David Kilzer (:ddkilzer) 2006-02-07 20:41:43 PST
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.
Comment 4 David Kilzer (:ddkilzer) 2006-02-07 20:44:48 PST
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.)
Comment 5 Darin Adler 2006-02-08 09:30:08 PST
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:


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.
Comment 6 Darin Adler 2006-02-19 12:45:38 PST
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.
Comment 7 Darin Adler 2006-02-19 12:53:06 PST
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.
Comment 8 Alice Liu 2006-03-20 07:05:39 PST
Comment 9 Maciej Stachowiak 2006-03-28 01:40:30 PST
Created attachment 7352 [details]
a fix
Comment 10 David Kilzer (:ddkilzer) 2006-03-29 21:38:54 PST
Verified fixed on locally-built r13568.  (Fix committed as r13530.)
Comment 11 Dave Hyatt 2006-03-30 01:59:32 PST
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.
Comment 12 Mark Rowe (bdash) 2006-07-10 21:50:57 PDT
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.
Comment 13 Darin Adler 2006-07-10 22:00:42 PDT
I think you're right. That other bug fix did fix this one!