<?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>112292</bug_id>
          
          <creation_ts>2013-03-13 14:31:10 -0700</creation_ts>
          <short_desc>Fix flaky fast/innerHTML/innerHTML-iframe.html test</short_desc>
          <delta_ts>2013-03-13 18:09:34 -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>New Bugs</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>DUPLICATE</resolution>
          <dup_id>112306</dup_id>
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="James Robinson">jamesr</reporter>
          <assigned_to name="James Robinson">jamesr</assigned_to>
          <cc>abarth</cc>
    
    <cc>eric</cc>
    
    <cc>jschuh</cc>
    
    <cc>tonyg</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>854629</commentid>
    <comment_count>0</comment_count>
    <who name="James Robinson">jamesr</who>
    <bug_when>2013-03-13 14:31:10 -0700</bug_when>
    <thetext>Fix flaky fast/innerHTML/innerHTML-iframe.html test</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854635</commentid>
    <comment_count>1</comment_count>
      <attachid>192994</attachid>
    <who name="James Robinson">jamesr</who>
    <bug_when>2013-03-13 14:32:04 -0700</bug_when>
    <thetext>Created attachment 192994
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854636</commentid>
    <comment_count>2</comment_count>
    <who name="James Robinson">jamesr</who>
    <bug_when>2013-03-13 14:32:35 -0700</bug_when>
    <thetext>Another day, another flaky test due to assumptions about timeouts firing vs the &lt;body&gt; tag existing.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854637</commentid>
    <comment_count>3</comment_count>
    <who name="James Robinson">jamesr</who>
    <bug_when>2013-03-13 14:32:52 -0700</bug_when>
    <thetext>Test history:

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2FinnerHTML%2FinnerHTML-iframe.html

and example failure diff:

CONSOLE MESSAGE: line 12: Uncaught TypeError: Cannot set property &apos;innerHTML&apos; of null
PASS: body and iframe cleared without crashing.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854640</commentid>
    <comment_count>4</comment_count>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2013-03-13 14:34:07 -0700</bug_when>
    <thetext>Do you believe these tests are more flaky since we turned on the threadded parser?  Or is it just that you&apos;re the first one to go after flaky tests in a while?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854642</commentid>
    <comment_count>5</comment_count>
    <who name="James Robinson">jamesr</who>
    <bug_when>2013-03-13 14:35:18 -0700</bug_when>
    <thetext>(In reply to comment #4)
&gt; Do you believe these tests are more flaky since we turned on the threadded parser?  Or is it just that you&apos;re the first one to go after flaky tests in a while?

That&apos;s a really good question that I was about to ping one of y&apos;all about.  It could be that things are worse, it could also be that things have always been this bad and I haven&apos;t noticed since I haven&apos;t gardened in many months.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854645</commentid>
    <comment_count>6</comment_count>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2013-03-13 14:36:47 -0700</bug_when>
    <thetext>By far our biggest problem getting the threaded parser to pass all the tests was dealing with all the assumptions tests made about when the document was considered complete.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854648</commentid>
    <comment_count>7</comment_count>
      <attachid>192994</attachid>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2013-03-13 14:38:45 -0700</bug_when>
    <thetext>Comment on attachment 192994
Patch

I&apos;m not really sure what this test is trying to test.  It appears to be trying to make sure that x is destroyed before the onload can run?  if the timeout fires before the onload does than the onload will fail?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854696</commentid>
    <comment_count>8</comment_count>
    <who name="James Robinson">jamesr</who>
    <bug_when>2013-03-13 15:07:12 -0700</bug_when>
    <thetext>(In reply to comment #4)
&gt; Do you believe these tests are more flaky since we turned on the threadded parser?  Or is it just that you&apos;re the first one to go after flaky tests in a while?

If I run this test (without this patch) with --repeat-each=50 --iterations=50 in debug mode on my linux box, I get 20-30 failures out of the 2500 runs.  If I do the same thing but also pass --additional-drt-flags=--disable-threaded-html-parser I get 0/2500 failures.  So this test, at least, is definitely flakier with the threaded parser on than with it off.  Are the yielding criteria different?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854702</commentid>
    <comment_count>9</comment_count>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2013-03-13 15:20:17 -0700</bug_when>
    <thetext>Sure.  Very different. The background thread yields every &lt;/script&gt; or 1000 tokens.  We&apos;ll get up to the &lt;/script&gt; from the background thread and process it.  If the background thread has not yet sent us the next block of data (very possible) we&apos;ll yield back to the main run loop, which will execute the javascript from the 0ms timer.

The main thread would execute the inline script synchronously, but not need to yield (since it can just keep going after the script) so it will always finish parsing the rest before the end.

You could insert 4000 tokens beteween the &lt;script&gt; and the &lt;body&gt; and then the main thread parser will always yield before it hits the body. :)  Or if HTTP had a packet break between the &lt;/script&gt; And the &lt;body&gt;. :)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854703</commentid>
    <comment_count>10</comment_count>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2013-03-13 15:21:13 -0700</bug_when>
    <thetext>Scripts execute on teh main thread, but tokens are produced on the bakground thread.  Since every &lt;/script&gt; may indicate that we need to execute scripts, we send tokens in chunks of 1000 or up to the next &lt;/script&gt; or EOF whichever comes sooner.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>854832</commentid>
    <comment_count>11</comment_count>
    <who name="James Robinson">jamesr</who>
    <bug_when>2013-03-13 18:09:27 -0700</bug_when>
    <thetext>More comprehensive set of fixes here: bug 112306

*** This bug has been marked as a duplicate of bug 112306 ***</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>192994</attachid>
            <date>2013-03-13 14:32:04 -0700</date>
            <delta_ts>2013-03-13 18:09:34 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-112292-20130313142802.patch</filename>
            <type>text/plain</type>
            <size>1996</size>
            <attacher name="James Robinson">jamesr</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMTQ1NzM4CmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9DaGFu
Z2VMb2cgYi9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKaW5kZXggMDE2YTVlM2U2ODBhY2UzNDcyMmZh
ZWYyZTcyMGQwYTgyNjM3ODMxYy4uNDBlZDlkYmU2MDUyZTAxMWYzYjFlNTc4MmQ4NTcwOGJiNDZk
NjBkYiAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCisrKyBiL0xheW91dFRlc3Rz
L0NoYW5nZUxvZwpAQCAtMSw1ICsxLDE4IEBACiAyMDEzLTAzLTEzICBKYW1lcyBSb2JpbnNvbiAg
PGphbWVzckBjaHJvbWl1bS5vcmc+CiAKKyAgICAgICAgRml4IGZsYWt5IGZhc3QvaW5uZXJIVE1M
L2lubmVySFRNTC1pZnJhbWUuaHRtbCB0ZXN0CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu
b3JnL3Nob3dfYnVnLmNnaT9pZD0xMTIyOTIKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkg
KE9PUFMhKS4KKworICAgICAgICBUaGlzIHRlc3QgY2FsbHMgc2V0VGltZW91dCguLi4sIDApIGlu
IGFuIGlubGluZSBzY3JpcHQgaW4gdGhlIDxoZWFkPiBhbmQgYXNzdW1lcyB0aGF0IHdoZW4gdGhl
IHRpbWVvdXQgZmlyZXMKKyAgICAgICAgdGhhdCBkb2N1bWVudC5ib2R5IHdpbGwgYmUgdGhlcmUu
IERlcGVuZGluZyBvbiB0aGUgdGltaW5nIG9mIHRoZSB0aW1lb3V0LCBzb21ldGltZXMgaXQncyBu
b3QgdGhlcmUuIFRoaXMgbW92ZXMKKyAgICAgICAgdGhlIHNjcmlwdCBpbnRvIHRoZSA8Ym9keT4K
KworICAgICAgICAqIGZhc3QvaW5uZXJIVE1ML2lubmVySFRNTC1pZnJhbWUuaHRtbDoKKworMjAx
My0wMy0xMyAgSmFtZXMgUm9iaW5zb24gIDxqYW1lc3JAY2hyb21pdW0ub3JnPgorCiAgICAgICAg
IENsZWFuIG91dCBzb21lIHN0YWxlIGNocm9taXVtIFRlc3RFeHBlY3RhdGlvbnMgZW50cmllcy4K
IAogICAgICAgICAqIHBsYXRmb3JtL2Nocm9taXVtL1Rlc3RFeHBlY3RhdGlvbnM6CmRpZmYgLS1n
aXQgYS9MYXlvdXRUZXN0cy9mYXN0L2lubmVySFRNTC9pbm5lckhUTUwtaWZyYW1lLmh0bWwgYi9M
YXlvdXRUZXN0cy9mYXN0L2lubmVySFRNTC9pbm5lckhUTUwtaWZyYW1lLmh0bWwKaW5kZXggNGM4
ZDZiZjUxMDgxOTY3MmRmMzNmZWYwYmIzMWYzOTYzODU0ZGIwYS4uOGUwNzA5N2M0NjM2YzMyZjYx
ZDc3YWYxMTFhNjkyYzdlZGYwNzI5YiAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvZmFzdC9pbm5l
ckhUTUwvaW5uZXJIVE1MLWlmcmFtZS5odG1sCisrKyBiL0xheW91dFRlc3RzL2Zhc3QvaW5uZXJI
VE1ML2lubmVySFRNTC1pZnJhbWUuaHRtbApAQCAtMSwxNSArMSwxNSBAQAotPHNjcmlwdD4KLWlm
ICh3aW5kb3cudGVzdFJ1bm5lcikgewotICAgIHRlc3RSdW5uZXIuZHVtcEFzVGV4dCgpOwotICAg
IHRlc3RSdW5uZXIud2FpdFVudGlsRG9uZSgpOwotfQotCi1zZXRUaW1lb3V0KGZ1bmN0aW9uKCl7
Ci0gICAgICAgIGRvY3VtZW50LmJvZHkuaW5uZXJIVE1MID0gIjxiPlBBU1M6PC9iPiBib2R5IGFu
ZCBpZnJhbWUgY2xlYXJlZCB3aXRob3V0IGNyYXNoaW5nLiI7Ci0gICAgICAgIHRlc3RSdW5uZXIu
bm90aWZ5RG9uZSgpOwotICAgIH0sIDApOwotPC9zY3JpcHQ+CiA8Ym9keSBvbmxvYWQ9J2RvY3Vt
ZW50LmdldEVsZW1lbnRCeUlkKCJ4IikuaW5uZXJIVE1MID0gIiInPgorICA8c2NyaXB0PgorICBp
ZiAod2luZG93LnRlc3RSdW5uZXIpIHsKKyAgICAgIHRlc3RSdW5uZXIuZHVtcEFzVGV4dCgpOwor
ICAgICAgdGVzdFJ1bm5lci53YWl0VW50aWxEb25lKCk7CisgIH0KKworICBzZXRUaW1lb3V0KGZ1
bmN0aW9uKCl7CisgICAgICAgICAgZG9jdW1lbnQuYm9keS5pbm5lckhUTUwgPSAiPGI+UEFTUzo8
L2I+IGJvZHkgYW5kIGlmcmFtZSBjbGVhcmVkIHdpdGhvdXQgY3Jhc2hpbmcuIjsKKyAgICAgICAg
ICB0ZXN0UnVubmVyLm5vdGlmeURvbmUoKTsKKyAgICAgIH0sIDApOworICA8L3NjcmlwdD4KICAg
PGRpdiBpZD0ieCI+CiAgICAgPGlmcmFtZSBzcmM9ImRvZXMtbm90LWV4aXN0Ij4KICAgPC9kaXY+
Cg==
</data>

          </attachment>
      

    </bug>

</bugzilla>