Bug 112292

Summary: Fix flaky fast/innerHTML/innerHTML-iframe.html test
Product: WebKit Reporter: James Robinson <jamesr>
Component: New BugsAssignee: James Robinson <jamesr>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: abarth, eric, jschuh, tonyg
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch none

James Robinson
Reported 2013-03-13 14:31:10 PDT
Fix flaky fast/innerHTML/innerHTML-iframe.html test
Attachments
Patch (1.95 KB, patch)
2013-03-13 14:32 PDT, James Robinson 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
James Robinson
Comment 1 2013-03-13 14:32:04 PDT
Created attachment 192994 [details] Patch
James Robinson
Comment 2 2013-03-13 14:32:35 PDT
Another day, another flaky test due to assumptions about timeouts firing vs the <body> tag existing.
James Robinson
Comment 3 2013-03-13 14:32:52 PDT
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 'innerHTML' of null PASS: body and iframe cleared without crashing.
Eric Seidel (no email)
Comment 4 2013-03-13 14:34:07 PDT
Do you believe these tests are more flaky since we turned on the threadded parser? Or is it just that you're the first one to go after flaky tests in a while?
James Robinson
Comment 5 2013-03-13 14:35:18 PDT
(In reply to comment #4) > Do you believe these tests are more flaky since we turned on the threadded parser? Or is it just that you're the first one to go after flaky tests in a while? That's a really good question that I was about to ping one of y'all about. It could be that things are worse, it could also be that things have always been this bad and I haven't noticed since I haven't gardened in many months.
Eric Seidel (no email)
Comment 6 2013-03-13 14:36:47 PDT
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.
Eric Seidel (no email)
Comment 7 2013-03-13 14:38:45 PDT
Comment on attachment 192994 [details] Patch I'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?
James Robinson
Comment 8 2013-03-13 15:07:12 PDT
(In reply to comment #4) > Do you believe these tests are more flaky since we turned on the threadded parser? Or is it just that you'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?
Eric Seidel (no email)
Comment 9 2013-03-13 15:20:17 PDT
Sure. Very different. The background thread yields every </script> or 1000 tokens. We'll get up to the </script> from the background thread and process it. If the background thread has not yet sent us the next block of data (very possible) we'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 <script> and the <body> and then the main thread parser will always yield before it hits the body. :) Or if HTTP had a packet break between the </script> And the <body>. :)
Eric Seidel (no email)
Comment 10 2013-03-13 15:21:13 PDT
Scripts execute on teh main thread, but tokens are produced on the bakground thread. Since every </script> may indicate that we need to execute scripts, we send tokens in chunks of 1000 or up to the next </script> or EOF whichever comes sooner.
James Robinson
Comment 11 2013-03-13 18:09:27 PDT
More comprehensive set of fixes here: bug 112306 *** This bug has been marked as a duplicate of bug 112306 ***
Note You need to log in before you can comment on or make changes to this bug.