Bug 72134 – [chromium] WorkerTest flakiness

• Component: WebKit Misc.
• Status: RESOLVED WONTFIX

[Sadrul Habib Chowdhury]

The worker tests have been flaking in different platforms for a while. This is a speculative fix.

[Sadrul Habib Chowdhury]

Created attachment 114705 [details]
patch

[Sadrul Habib Chowdhury]

If this does fix the flakiness, then presumably similar fixes can be applied to a number of other worker tests.

[David Levin]

Comment on attachment 114705 [details]
patch

The patch doesn't seem to apply (purple bots) and this needs a changelog (which would hopefully explain why this is thought to possibly fix the problem).

[Sadrul Habib Chowdhury]

Created attachment 114713 [details]
patch

I created the diff from the chrome tree, so it didn't apply correctly. I have prepared this new patch from the webkit tree, and included a description in the ChangeLog. (a sample log from a failure: http://build.chromium.org/p/chromium/builders/Linux%20Tests%20%28dbg%29%28shared%29/builds/3742/steps/ui_tests/logs/WorkerCall)

[Dmitry Lomov]

Cool - really sounds plausible.
I wonder why we haven't seen these before.

[Tony Chang]

Comment on attachment 114713 [details]
patch

Seem worth trying.  If this does fix the flakiness, it sounds like it's a bug in our ui_test test harness.  We should try to fix the test harness or people will add new tests that are flaky in the same way.

[Tony Chang]

CQ appears to be down.  I will try to land manually.

[Tony Chang]

Committed r99990: <http://trac.webkit.org/changeset/99990>

[Tony Chang]

Comment on attachment 114713 [details]
patch

I fixed the formatting of the ChangeLog and the indenting before landing.

[Andrew Wilson]

I don't think this change is bad, but if we ever have a case where:

<p>Some text</p>
<script>...some javascript...</script>

executes the javascript before the HTML is populated in the DOM, then that indicates a fundamental issue with our HTML rendering that should be fixed, not worked around.

So, yeah, if this "speculative fix" actually fixes the flakiness, then we really need to log a separate bug to address that behavior.

[Dmitry Lomov]

(In reply to comment #10)
> I don't think this change is bad, but if we ever have a case where:
> 
> <p>Some text</p>
> <script>...some javascript...</script>
> 
> executes the javascript before the HTML is populated in the DOM, then that indicates a fundamental issue with our HTML rendering that should be fixed, not worked around.
> 
> So, yeah, if this "speculative fix" actually fixes the flakiness, then we really need to log a separate bug to address that behavior.

Right, it must be a ui_test harness bug, as Tony suggests.

[Ojan Vafai]

Reverted r99990 for reason:

Caused worker tests to fail on the chromium bots.

Committed r100023: <http://trac.webkit.org/changeset/100023>

[Ojan Vafai]

http://build.chromium.org/p/chromium.webkit/builders/Linux%20Tests/builds/15831/steps/ui_tests/logs/WorkerCloseFast
http://build.chromium.org/p/chromium.webkit/builders/Linux%20Tests/builds/15831/steps/ui_tests/logs/WorkerMessagePortGC

[Stephen Chenney]

Marking test failures as WontFix. Bug is still accessible and recording in TestExpectations.