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
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
credentials-in-url.https.window.js
// META: script=/service-workers/service-worker/resources/test-helpers.sub.js
// META: script=resources/utils.js
'use strict';
// "If parsedURL includes credentials, then throw a TypeError."
// https://fetch.spec.whatwg.org/#dom-request
// (Added by https://github.com/whatwg/fetch/issues/26).
// "A URL includes credentials if its username or password is not the empty
// string."
// https://url.spec.whatwg.org/#include-credentials
backgroundFetchTest((t, bgFetch) => {
return bgFetch.fetch(uniqueTag(), 'https://example.com');
}, 'fetch without credentials in URL should register ok');
backgroundFetchTest((t, bgFetch) => {
return promise_rejects(
t, new TypeError(),
bgFetch.fetch(uniqueTag(), 'https://username:password@example.com'));
}, 'fetch with username and password in URL should reject');
backgroundFetchTest((t, bgFetch) => {
return promise_rejects(
t, new TypeError(),
bgFetch.fetch(uniqueTag(), 'https://username:@example.com'));
}, 'fetch with username and empty password in URL should reject');
backgroundFetchTest((t, bgFetch) => {
return promise_rejects(
t, new TypeError(),
bgFetch.fetch(uniqueTag(), 'https://:password@example.com'));
}, 'fetch with empty username and password in URL should reject');
Computing file changes ...