<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>7102</bug_id>
          
          <creation_ts>2006-02-06 06:43:15 -0800</creation_ts>
          <short_desc>REGRESSION: parse mode gets set to strict after going back from non-HTML content</short_desc>
          <delta_ts>2006-07-10 22:00:42 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>WebKit Misc.</component>
          <version>420+</version>
          <rep_platform>Mac</rep_platform>
          <op_sys>OS X 10.4</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>HasReduction, InRadar, Regression</keywords>
          <priority>P1</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="David Kilzer (:ddkilzer)">ddkilzer</reporter>
          <assigned_to name="Maciej Stachowiak">mjs</assigned_to>
          <cc>alice.barraclough</cc>
    
    <cc>darin</cc>
    
    <cc>mitz</cc>
    
    <cc>mrowe</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>31565</commentid>
    <comment_count>0</comment_count>
    <who name="David Kilzer (:ddkilzer)">ddkilzer</who>
    <bug_when>2006-02-06 06:43:15 -0800</bug_when>
    <thetext>Summary: 

Clicking &quot;Back&quot; 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 &quot;Results MM - NN of about Y,YYY,YYY for &lt;search criteria&gt; (D.DD seconds)&quot; text appears much larger than it should.

1. Search for some PDF documents in Google.

http://www.google.com/search?q=filetype:pdf+pdf&amp;hl=en&amp;lr=&amp;safe=off&amp;start=10&amp;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 &quot;Back&quot; button.

4. If the web page draws correctly, click the &quot;Forward&quot; button, then the &quot;Back&quot; 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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>31566</commentid>
    <comment_count>1</comment_count>
    <who name="David Kilzer (:ddkilzer)">ddkilzer</who>
    <bug_when>2006-02-06 06:57:13 -0800</bug_when>
    <thetext>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.

&gt; 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 &quot;Back&quot;, click &quot;Forward&quot;, then click &quot;Back&quot; once again to reproduce the problem.  (This works every time I&apos;ve tried).

Bug 7085 may be related since it involves PDFs and the &quot;Back&quot; button.
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>31568</commentid>
    <comment_count>2</comment_count>
    <who name="David Kilzer (:ddkilzer)">ddkilzer</who>
    <bug_when>2006-02-06 07:00:42 -0800</bug_when>
    <thetext>I was able to reproduce this bug with WebKit nightly build r12596.
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>31804</commentid>
    <comment_count>3</comment_count>
      <attachid>6338</attachid>
    <who name="David Kilzer (:ddkilzer)">ddkilzer</who>
    <bug_when>2006-02-07 20:41:43 -0800</bug_when>
    <thetext>Created attachment 6338
Test case

Here&apos;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 &quot;Back&quot; button once.
4. Click &quot;Forward button once.
5. Click &quot;Back&quot; button once.

The thin, blue line above the PDF link is now much wider.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>31805</commentid>
    <comment_count>4</comment_count>
    <who name="David Kilzer (:ddkilzer)">ddkilzer</who>
    <bug_when>2006-02-07 20:44:48 -0800</bug_when>
    <thetext>After careful inspect of Google&apos;s results page, it&apos;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.)
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>31827</commentid>
    <comment_count>5</comment_count>
    <who name="Darin Adler">darin</who>
    <bug_when>2006-02-08 09:30:08 -0800</bug_when>
    <thetext>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&apos;s the table cell that ends up with too large a height. And it&apos;s definitely a back/forward cache bug. Turning the back/forward cache off with the Debug menu makes the bug go away.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>33406</commentid>
    <comment_count>6</comment_count>
    <who name="Darin Adler">darin</who>
    <bug_when>2006-02-19 12:45:38 -0800</bug_when>
    <thetext>The bug is that when we go back, we&apos;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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>33407</commentid>
    <comment_count>7</comment_count>
    <who name="Darin Adler">darin</who>
    <bug_when>2006-02-19 12:53:06 -0800</bug_when>
    <thetext>This is clearly a bug in the way the back/forward caching works. The bug doesn&apos;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 &quot;end&quot; it thinks it&apos;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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37001</commentid>
    <comment_count>8</comment_count>
    <who name="Alice Liu">alice.barraclough</who>
    <bug_when>2006-03-20 07:05:39 -0800</bug_when>
    <thetext>&lt;rdar://problem/4483851&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37750</commentid>
    <comment_count>9</comment_count>
      <attachid>7352</attachid>
    <who name="Maciej Stachowiak">mjs</who>
    <bug_when>2006-03-28 01:40:30 -0800</bug_when>
    <thetext>Created attachment 7352
a fix</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37933</commentid>
    <comment_count>10</comment_count>
    <who name="David Kilzer (:ddkilzer)">ddkilzer</who>
    <bug_when>2006-03-29 21:38:54 -0800</bug_when>
    <thetext>Verified fixed on locally-built r13568.  (Fix committed as r13530.)
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37952</commentid>
    <comment_count>11</comment_count>
      <attachid>7352</attachid>
    <who name="Dave Hyatt">hyatt</who>
    <bug_when>2006-03-30 01:59:32 -0800</bug_when>
    <thetext>Comment on attachment 7352
a fix

The change for this bug has been rolled out since it broke Spinneret and it&apos;s easy to roll back in with proper testing later.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>49156</commentid>
    <comment_count>12</comment_count>
    <who name="Mark Rowe (bdash)">mrowe</who>
    <bug_when>2006-07-10 21:50:57 -0700</bug_when>
    <thetext>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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>49160</commentid>
    <comment_count>13</comment_count>
    <who name="Darin Adler">darin</who>
    <bug_when>2006-07-10 22:00:42 -0700</bug_when>
    <thetext>I think you&apos;re right. That other bug fix did fix this one!</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>6338</attachid>
            <date>2006-02-07 20:41:43 -0800</date>
            <delta_ts>2006-02-07 20:41:43 -0800</delta_ts>
            <desc>Test case</desc>
            <filename>bug-7102-testcase.html</filename>
            <type>text/html</type>
            <size>230</size>
            <attacher name="David Kilzer (:ddkilzer)">ddkilzer</attacher>
            
              <data encoding="base64">PHRhYmxlIHdpZHRoPTEwMCUgYm9yZGVyPTAgY2VsbHBhZGRpbmc9MCBjZWxsc3BhY2luZz0wPjx0
cj48dGQgYmdjb2xvcj0jMzM2NmNjPjxpbWcgd2lkdGg9MSBoZWlnaHQ9MSBhbHQ9IiI+PC90ZD48
L3RyPjwvdGFibGU+CjxkaXY+PGEgaHJlZj0iaHR0cDovL3d3dy5pcnMuZ292L3B1Yi9pcnMtcGRm
L2Z3NC5wZGYiPmh0dHA6Ly93d3cuaXJzLmdvdi9wdWIvaXJzLXBkZi9mdzQucGRmPC9hPjwvZGl2
Pgo=
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>7352</attachid>
            <date>2006-03-28 01:40:30 -0800</date>
            <delta_ts>2006-03-30 01:59:32 -0800</delta_ts>
            <desc>a fix</desc>
            <filename>accidental-strict-mode.patch.txt</filename>
            <type>text/plain</type>
            <size>3443</size>
            <attacher name="Maciej Stachowiak">mjs</attacher>
            
              <data encoding="base64">SW5kZXg6IG1hbnVhbC10ZXN0cy9hY2NpZGVudGFsLXN0cmljdC1tb2RlLmh0bWwKPT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PQotLS0gbWFudWFsLXRlc3RzL2FjY2lkZW50YWwtc3RyaWN0LW1vZGUuaHRtbAkocmV2aXNpb24g
MCkKKysrIG1hbnVhbC10ZXN0cy9hY2NpZGVudGFsLXN0cmljdC1tb2RlLmh0bWwJKHJldmlzaW9u
IDApCkBAIC0wLDAgKzEsMTMgQEAKKzxwPlRoaXMgdGVzdHMgZm9yIHJlZ3Jlc3Npb24gYWdhaW5z
dCA8YSBocmVmPSJodHRwOi8vYnVnemlsbGEub3BlbmRhcndpbi5vcmcvc2hvd19idWcuY2dpP2lk
PTcxMDIiPlJFR1JFU1NJT046IHBhcnNlIG1vZGUgZ2V0cyBzZXQgdG8gc3RyaWN0IGFmdGVyIGdv
aW5nIGJhY2sgZnJvbSBub24tSFRNTCBjb250ZW50PC9wPgorCis8b2w+Cis8bGk+IENsaWNrIG9u
IFBERiBsaW5rIGJlbG93LiAgV2FpdCBmb3IgUERGIHRvIGZ1bGx5IGxvYWQuCis8bGk+IENsaWNr
ICJCYWNrIiBidXR0b24gb25jZS4KKzxsaT4gQ2xpY2sgdGhlIGxpbmsgYWdhaW4uCis8bGk+IENs
aWNrICJCYWNrIiBidXR0b24gb25jZS4KKzwvb2w+CisKKzxwPkluIHRoZSBmYWlsaW5nIGNhc2Us
IHRoZSB0aGluIGxpbmUgYWJvdmUgdGhlIGxpbmsgd2lsbCBnZXQgbXVjaCB0aGlja2VyLiBJZiBp
dCByZW1haW5zIHRoZSBzYW1lLCB0aGlzIHRlc3QgaGFzIHBhc3NlZC48L3A+CisKKzx0YWJsZSB3
aWR0aD0xMDAlIGJvcmRlcj0wIGNlbGxwYWRkaW5nPTAgY2VsbHNwYWNpbmc9MD48dHI+PHRkIGJn
Y29sb3I9IzMzNjZjYz48aW1nIHdpZHRoPTEgaGVpZ2h0PTEgYWx0PSIiPjwvdGQ+PC90cj48L3Rh
YmxlPgorPGRpdj48YSBocmVmPSJodHRwOi8vd3d3Lmlycy5nb3YvcHViL2lycy1wZGYvZnc0LnBk
ZiI+aHR0cDovL3d3dy5pcnMuZ292L3B1Yi9pcnMtcGRmL2Z3NC5wZGY8L2E+PC9kaXY+CkluZGV4
OiBDaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PQotLS0gQ2hhbmdlTG9nCShyZXZpc2lvbiAxMzUyNikKKysr
IENoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE5IEBACisyMDA2LTAzLTI4ICBN
YWNpZWogU3RhY2hvd2lhayAgPG1qc0BhcHBsZS5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkg
Tk9CT0RZIChPT1BTISkuCisgICAgICAgIAorICAgICAgICAtIGZpeGVkIDxyZGFyOi8vcHJvYmxl
bS80NDgzODUxPiBSRUdSRVNTSU9OOiBwYXJzZSBtb2RlIGdldHMgc2V0IHRvIHN0cmljdCBhZnRl
ciBnb2luZyBiYWNrIGZyb20gbm9uLUhUTUwgY29udGVudCAoNzEwMikKKworICAgICAgICBSZXNo
dWZmbGVkIHRoaW5ncyB0byBhcnJhbmdlIGZvciBtX2RvYyB0byBiZSBjbGVhcmVkIHNvbWV3aGF0
IGVhcmxpZXIgdGhhbiBiZWZvcmUuCisgICAgICAgIAorICAgICAgICAqIHBhZ2UvRnJhbWUuY3Bw
OgorICAgICAgICAoV2ViQ29yZTo6RnJhbWU6OmRpZE9wZW5VUkwpOgorICAgICAgICAoV2ViQ29y
ZTo6RnJhbWU6OnJlY2VpdmVkRmlyc3REYXRhKToKKyAgICAgICAgKFdlYkNvcmU6OkZyYW1lOjpi
ZWdpbik6CisgICAgICAgIChXZWJDb3JlOjpGcmFtZTo6ZW5kSWZOb3RMb2FkaW5nKTogCisgICAg
ICAgICogbWFudWFsLXRlc3RzL2FjY2lkZW50YWwtc3RyaWN0LW1vZGUuaHRtbDogQWRkZWQuIEkg
ZG9uJ3QgdGhpbmsgYW4KKyAgICAgICAgYXV0b21hdGVkIHRlc3QgaXMgcG9zc2libGUuCisKIDIw
MDYtMDMtMjcgIE1hY2llaiBTdGFjaG93aWFrICA8bWpzQGFwcGxlLmNvbT4KIAogICAgICAgICBS
ZXZpZXdlZCBieSBCZXRoLgpJbmRleDogcGFnZS9GcmFtZS5jcHAKPT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gcGFn
ZS9GcmFtZS5jcHAJKHJldmlzaW9uIDEzNTI1KQorKysgcGFnZS9GcmFtZS5jcHAJKHdvcmtpbmcg
Y29weSkKQEAgLTI2MSw2ICsyNjEsOCBAQCBib29sIEZyYW1lOjpkaWRPcGVuVVJMKGNvbnN0IEtV
UkwmIHVybCkKIAogICBzdGFydGVkKCk7CiAKKyAgYmVnaW4oZC0+bV93b3JraW5nVVJMKTsKKwog
ICByZXR1cm4gdHJ1ZTsKIH0KIApAQCAtNDkyLDggKzQ5NCw2IEBAIHZvaWQgRnJhbWU6OnNldERv
Y3VtZW50KERvY3VtZW50KiBuZXdEb2MKIAogdm9pZCBGcmFtZTo6cmVjZWl2ZWRGaXJzdERhdGEo
KQogewotICAgIGJlZ2luKGQtPm1fd29ya2luZ1VSTCk7Ci0KICAgICBkLT5tX2RvYy0+ZG9jTG9h
ZGVyKCktPnNldENhY2hlUG9saWN5KGQtPm1fY2FjaGVQb2xpY3kpOwogICAgIGQtPm1fd29ya2lu
Z1VSTCA9IEtVUkwoKTsKIApAQCAtNjAyLDggKzYwMiwxMCBAQCB2b2lkIEZyYW1lOjpiZWdpbihj
b25zdCBLVVJMJiB1cmwpCiAKICAgaWYgKERPTUltcGxlbWVudGF0aW9uOjppc1hNTE1JTUVUeXBl
KGQtPm1fcmVxdWVzdC5tX3Jlc3BvbnNlTUlNRVR5cGUpKQogICAgIGQtPm1fZG9jID0gRE9NSW1w
bGVtZW50YXRpb246Omluc3RhbmNlKCktPmNyZWF0ZURvY3VtZW50KGQtPm1fdmlldy5nZXQoKSk7
Ci0gIGVsc2UKKyAgZWxzZSBpZiAoZC0+bV9yZXF1ZXN0Lm1fcmVzcG9uc2VNSU1FVHlwZSA9PSAi
dGV4dC9odG1sIikKICAgICBkLT5tX2RvYyA9IERPTUltcGxlbWVudGF0aW9uOjppbnN0YW5jZSgp
LT5jcmVhdGVIVE1MRG9jdW1lbnQoZC0+bV92aWV3LmdldCgpKTsKKyAgZWxzZQorICAgIHJldHVy
bjsKIAogICBpZiAoIWQtPm1fZG9jLT5hdHRhY2hlZCgpKQogICAgIGQtPm1fZG9jLT5hdHRhY2go
KTsKQEAgLTY5NiwxMSArNjk4LDExIEBAIHZvaWQgRnJhbWU6OmVuZElmTm90TG9hZGluZygpCiAg
ICAgICAgIHJldHVybjsKIAogICAgIC8vIG1ha2Ugc3VyZSBub3RoaW5nJ3MgbGVmdCBpbiB0aGVy
ZS4uLgotICAgIGlmIChkLT5tX2RlY29kZXIpCi0gICAgICAgIHdyaXRlKGQtPm1fZGVjb2Rlci0+
Zmx1c2goKSk7Ci0gICAgaWYgKGQtPm1fZG9jKQorICAgIGlmIChkLT5tX2RvYykgeworICAgICAg
ICBpZiAoZC0+bV9kZWNvZGVyKQorICAgICAgICAgICAgd3JpdGUoZC0+bV9kZWNvZGVyLT5mbHVz
aCgpKTsKICAgICAgICAgZC0+bV9kb2MtPmZpbmlzaFBhcnNpbmcoKTsKLSAgICBlbHNlCisgICAg
fSBlbHNlCiAgICAgICAgIC8vIFdlYktpdCBwYXJ0aWFsbHkgdXNlcyBXZWJDb3JlIHdoZW4gbG9h
ZGluZyBub24tSFRNTCBkb2NzLiAgSW4gdGhlc2UgY2FzZXMgZG9jPT1uaWwsIGJ1dAogICAgICAg
ICAvLyBXZWJDb3JlIGlzIGVub3VnaCBpbnZvbHZlZCB0aGF0IHdlIG5lZWQgdG8gY2hlY2tDb21w
bGV0ZWQoKSBpbiBvcmRlciBmb3IgbV9iQ29tcGxldGUgdG8KICAgICAgICAgLy8gYmVjb21lIHRy
dWUuICBBbiBleGFtcGxlIGlzIHdoZW4gYSBzdWJmcmFtZSBpcyBhIHB1cmUgdGV4dCBkb2MsIGFu
ZCB0aGF0IHN1YmZyYW1lIGlzIHRoZQo=
</data>
<flag name="review"
          id="1972"
          type_id="1"
          status="-"
          setter="hyatt"
    />
          </attachment>
      

    </bug>

</bugzilla>