The test LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-iframe-in-main-frame.html is flaky. It enables the option to dump frame load events. It then opens a new window. The result is that the load events of the window-opening-window and the load events of the opened-window are interleaved non-deterministically. <rdar://problem/39297079>
data-url-iframe-in-main-frame.html seems like it should have the same issue, in that it enables load event dumping and then calls window.open().
Also: * insecure-css-in-main-frame.html * insecure-image-in-main-frame.html * insecure-plugin-in-main-frame.html * insecure-script-in-main-frame.html * insecure-xhr-asynchronous-in-main-frame.html * insecure-xhr-synchronous-in-main-frame.html * about-blank-iframe-in-main-frame.html * data-url-iframe-in-main-frame.html * insecure-css-in-main-frame.html * insecure-css-with-secure-cookies.html * insecure-executable-css-with-secure-cookies.html * insecure-form-in-main-frame.html * insecure-iframe-in-main-frame.html * javascript-url-form-in-main-frame.html * redirect-http-to-https-iframe-in-main-frame.html * redirect-https-to-http-iframe-in-main-frame.html * redirect-https-to-http-image-secure-cookies-block.html * redirect-https-to-http-image-secure-cookies.html
The difference may be related to the following code in insecure-iframe-in-main-frame.html: // FIXME: For some reason a SecurityPolicyViolation event is not dispatched in frame-with-insecure-iframe.html (why?). // So, dump-securitypolicyviolation-and-notify-done.js loaded by frame-with-insecure-iframe.html will never call // testRunner.notifyDone(). For now we do not call testRunner.waitUntilDone() and instead wait a fixed timeout :( window.setTimeout(function () { if (window.testRunner) testRunner.notifyDone(); }, 500); I note that, the comment notwithstanding, waitUntilDone is indeed called. I also note that the following tests have similar comments, but that they don't go so far as including the timeout code: * insecure-iframe-in-iframe.html * insecure-image-in-javascript-url-iframe-in-iframe.html
Ultimately, the issue is not with determinism. If the expected results for this test are rebased, we’ll pass the test every time. The issue was that the order in which events of interleaved windows are reported was changed. Most other tests affected by this change had their expected results changed. However, this particular test was not treated in the same way because it was marked as flaky. Since it was expected to occasionally fail, the fact that it now *always* failed was missed. I'm (a) rebasing the expected results and (b) tweaking the test so that the two windows are not opening at the same time and so aren't having their frame-load events interleaved.
Created attachment 337632 [details] Patch
Comment on attachment 337632 [details] Patch Clearing flags on attachment: 337632 Committed r230590: <https://trac.webkit.org/changeset/230590>
All reviewed patches have been landed. Closing bug.
Comment on attachment 337632 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=337632&action=review > LayoutTests/http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-iframe-in-main-frame.html:34 > + window.setTimeout(function() { setTimeout(0) still does not guarantee the current page will have loaded. We may want to do the setTimeout(0) in in unload = function() { }.