Bug 179195 – LayoutTest http/tests/security/cross-frame-access-put.html is a flaky failure

• Component: New Bugs
• Status: RESOLVED FIXED

[Ryan Haddad]

LayoutTest http/tests/security/cross-frame-access-put.html is a flaky failure

https://build.webkit.org/results/Apple%20Sierra%20Debug%20WK2%20(Tests)/r224335%20(3841)/results.html

https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Ftests%2Fsecurity%2Fcross-frame-access-put.html

[Alexey Proskuryakov]

It looks like the test pretty much works properly, but dumps the results as a render tree instead of text!

Very curious, I wonder if this reproduces locally.

[Ryan Haddad]

I can reproduce locally with: 
run-webkit-tests http/tests/security/cross-frame-access-put.html -fg --iter 10 --no-retry-failure

[Chris Dumez]

Created attachment 326218 [details]
Patch

[Chris Dumez]

(In reply to Ryan Haddad from comment #2)
> I can reproduce locally with: 
> run-webkit-tests http/tests/security/cross-frame-access-put.html -fg --iter
> 10 --no-retry-failure

Thanks for the repro steps Ryan, they worked.

[Alexey Proskuryakov]

Comment on attachment 326218 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=326218&action=review

> LayoutTests/ChangeLog:9
> +        Fix flaky test by calling the testRunner functions as early as possible, not in
> +        the onload event handler.

Why does this matter?

[WebKit Commit Bot]

Comment on attachment 326218 [details]
Patch

Clearing flags on attachment: 326218

Committed r224538: <https://trac.webkit.org/changeset/224538>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Chris Dumez]

Comment on attachment 326218 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=326218&action=review

>> LayoutTests/ChangeLog:9
>> +        the onload event handler.
> 
> Why does this matter?

Because the test can start running in the subframe *before* the onload event handler gets called in the top frame.

[Alexey Proskuryakov]

> Because the test can start running in the subframe *before* the onload event handler gets called in the top frame.

It definitely can, but how does this translate into the symptom? The test should still switch to text mode before any of the content is dumped in the end.

[Chris Dumez]

(In reply to Alexey Proskuryakov from comment #9)
> > Because the test can start running in the subframe *before* the onload event handler gets called in the top frame.
> 
> It definitely can, but how does this translate into the symptom? The test
> should still switch to text mode before any of the content is dumped in the
> end.

The test starts running in the subframe, then the subframes starts the test in the topFrame via a postMessage(). As far as I can tell, nothing prevented the test in the top frame to finish *before* the onload event handler was called in the main frame. Therefore, the test *could* finish *before* calling testRunner.dumpAsText() is called.

[Alexey Proskuryakov]

Any test that doesn't call waitUntilDone() finishes after onload is dispatched, so I still don't see how anything could go wrong.

I suspect that there is a deeper root cause, something with incorrect sequence of load event and API callbacks.

[Radar WebKit Bug Importer]

<rdar://problem/35567537>