Bug 1454091 [wpt PR 10467] - Reland 2: Use PostTask to schedule cross-process postMessage forwarding., a=testonly
authorAlex Moshchuk <alexmos@chromium.org>
Sun, 22 Apr 2018 15:14:15 +0000
changeset 468882 1679673e1d64e59a265d8a08f5c883d9c3a78eb5
parent 468881 fb03c240a2e225003cc30b0f054a51fe26eb129f
child 468883 de7ca81cd124d691b43c30172901697d04a3cdfe
push id9165
push userasasaki@mozilla.com
push dateThu, 26 Apr 2018 21:04:54 +0000
treeherdermozilla-beta@064c3804de2e [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
bugs1454091, 10467, 1011287, 999182, 832319, 828529, 550284, 550621, 1012472, 550769
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1454091 [wpt PR 10467] - Reland 2: Use PostTask to schedule cross-process postMessage forwarding., a=testonly Automatic update from web-platform-testsReland 2: Use PostTask to schedule cross-process postMessage forwarding. Changes from first reland attempt at https://crrev.com/c/1011287: - fix an additional source of flakiness in ChromeOS login tests Changes from original attempt at https://crrev.com/c/999182: - fix flakiness in two additional ChromeOS login tests - fix CSP WPT tests to not depend on ordering between iframe's onload and postMessage - see https://crbug.com/832319. Previously, we sent the IPC to forward a cross-process postMessage immediately. This caused a behavioral difference from the same-process case where the postMessage is always scheduled. Namely, in a scenario like this: frame.postMessage(...); doSomethingThatSendsIPCsToFrame(frame); the IPCs from JS following the postMessage would've been ordered incorrectly, causing |frame| to see their side effects after the postMessage dispatch in the cross-process case, whereas they would be seen before the postMessage dispatch in the same-process case. One example of this is frame.focus(), and another is a frame element onload event (dispatched via FrameHostMsg_DispatchLoad) arriving after a postMessage dispatched from an inline script while the frame was still loading. To resolve these ordering concerns, this CL changes cross-process postMessage to do a PostTask on the sender side before sending the message to the browser process. This improves the current state of the world, but does not yet achieve a perfect match for the IPC ordering in the same-process case - see discussion on the bug. Bug: 828529 Tbr: dcheng@chromium.org Change-Id: If2cc6591db31471adff0d84ec0b689905e21cdf1 Reviewed-on: https://chromium-review.googlesource.com/999182 Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Commit-Queue: Alex Moshchuk <alexmos@chromium.org> Cr-Original-Original-Commit-Position: refs/heads/master@{#550284} Reviewed-on: https://chromium-review.googlesource.com/1011287 Cr-Original-Commit-Position: refs/heads/master@{#550621} Reviewed-on: https://chromium-review.googlesource.com/1012472 Cr-Commit-Position: refs/heads/master@{#550769} -- wpt-commits: c53d084cc57749bc666e42aaceeb34daa42539c7 wpt-pr: 10467
--- a/testing/web-platform/meta/MANIFEST.json
+++ b/testing/web-platform/meta/MANIFEST.json
@@ -423628,17 +423628,17 @@
   "content-security-policy/embedded-enforcement/support/echo-required-csp.py": [
   "content-security-policy/embedded-enforcement/support/testharness-helper.sub.js": [
-   "23feae559098474ba96b15f07619b9d7dba12dec",
+   "3f5930842625b190576a163cbe1a01aa8fc4c086",
   "content-security-policy/font-src/font-match-allowed.sub.html": [
   "content-security-policy/font-src/font-mismatch-blocked.sub.html": [
--- a/testing/web-platform/tests/content-security-policy/embedded-enforcement/support/testharness-helper.sub.js
+++ b/testing/web-platform/tests/content-security-policy/embedded-enforcement/support/testharness-helper.sub.js
@@ -133,18 +133,24 @@ function assert_iframe_with_csp(t, url, 
     // Assert iframe loads with an expected violation.
     window.addEventListener('message', t.step_func(e => {
       if (e.source != i.contentWindow)
       assert_equals(e.data["blockedURI"], blockedURI);
   } else {
-    // Assert iframe loads.
+    // Assert iframe loads.  Wait for both the load event and the postMessage.
+    window.addEventListener('message', t.step_func(e => {
+      if (e.source != i.contentWindow)
+        return;
+      assert_true(loaded[urlId]);
+      if (i.onloadReceived)
+        t.done();
+    }));
     i.onload = t.step_func(function () {
-      // Delay the check until after the postMessage has a chance to execute.
-      setTimeout(t.step_func_done(function () {
-        assert_true(loaded[urlId]);
-      }), 1);
+      if (loaded[urlId])
+        t.done();
+      i.onloadReceived = true;