Skip to main content

Browse the archive

Revision 4e5f09f89e6f1976dd49a57ba46cd447c7e19a1e authored by Alex Moshchuk on 13 April 2018, 15:22:14 UTC, committed by Chromium WPT Sync on 13 April 2018, 15:22:14 UTC 
Reland: Use PostTask to schedule cross-process postMessage forwarding.
 
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
Change-Id: I62a627c501526d09900be4f5bd2c899acf4d1e07
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-Commit-Position: refs/heads/master@{#550284}
Reviewed-on: https://chromium-review.googlesource.com/1011287
Cr-Commit-Position: refs/heads/master@{#550621}
1 parent f90d3d6
Raw File
port-blocking.https.window.js 
// META: script=/service-workers/service-worker/resources/test-helpers.sub.js
// META: script=resources/utils.js
'use strict';

// Tests that requests to bad ports are blocked.
// https://fetch.spec.whatwg.org/#port-blocking

// This is not a comprehensive test of blocked ports - it is just intended to
// check that blocking is enabled.

backgroundFetchTest((t, bgFetch) => {
  return bgFetch.fetch(uniqueTag(), 'https://example.com');
}, 'fetch to default https port should register ok');

backgroundFetchTest((t, bgFetch) => {
  return bgFetch.fetch(uniqueTag(), 'http://127.0.0.1');
}, 'fetch to default http port should register ok');

backgroundFetchTest((t, bgFetch) => {
  return bgFetch.fetch(uniqueTag(), 'https://example.com:443');
}, 'fetch to port 443 should register ok');

backgroundFetchTest((t, bgFetch) => {
  return bgFetch.fetch(uniqueTag(), 'https://example.com:80');
}, 'fetch to port 80 should register ok, even over https');

backgroundFetchTest((t, bgFetch) => {
  return bgFetch.fetch(uniqueTag(), 'https://example.com:8080');
}, 'fetch to non-default non-bad port (8080) should register ok');

backgroundFetchTest((t, bgFetch) => {
  return promise_rejects(
      t, new TypeError(),
      bgFetch.fetch(uniqueTag(), 'https://example.com:587'));
}, 'fetch to bad port (SMTP) should reject');
back to top