WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
7102
REGRESSION: parse mode gets set to strict after going back from non-HTML content
https://bugs.webkit.org/show_bug.cgi?id=7102
Summary
REGRESSION: parse mode gets set to strict after going back from non-HTML content
David Kilzer (:ddkilzer)
Reported
2006-02-06 06:43:15 PST
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.
Attachments
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
View All
Add attachment
proposed patch, testcase, etc.
David Kilzer (:ddkilzer)
Comment 1
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.
David Kilzer (:ddkilzer)
Comment 2
2006-02-06 07:00:42 PST
I was able to reproduce this bug with WebKit nightly build
r12596
.
David Kilzer (:ddkilzer)
Comment 3
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.
David Kilzer (:ddkilzer)
Comment 4
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.)
Darin Adler
Comment 5
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:
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
Comment 6
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.
Darin Adler
Comment 7
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.
Alice Liu
Comment 8
2006-03-20 07:05:39 PST
<
rdar://problem/4483851
>
Maciej Stachowiak
Comment 9
2006-03-28 01:40:30 PST
Created
attachment 7352
[details]
a fix
David Kilzer (:ddkilzer)
Comment 10
2006-03-29 21:38:54 PST
Verified fixed on locally-built
r13568
. (Fix committed as
r13530
.)
Dave Hyatt
Comment 11
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.
Mark Rowe (bdash)
Comment 12
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.
Darin Adler
Comment 13
2006-07-10 22:00:42 PDT
I think you're right. That other bug fix did fix this one!
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug