Automatic update from web-platform-testsFetch: align about:blank handling with the standard
See 72fc2e787b.
Closes https://github.com/whatwg/xhr/issues/194.
--
wpt-commits: fa62ac066402b280c37623ee9ec45489939781fc
wpt-pr: 10421
Automatic update from web-platform-testsEnsure cloneNode() does not preserve the prototype
Closes https://github.com/whatwg/dom/issues/565.
--
wpt-commits: 691673d4de5105fab16f3b1a1d8523a5e9699fee
wpt-pr: 9987
Automatic update from web-platform-testsImprove handling of harness-level errors in wptrunner (#10444)
Split the internal handling of errors during a test into two cases;
INTERNAL-ERROR that is produced if there's an exception in the harness
and ERROR that is for exceptions reported by the test. Both are still
reported as ERROR to the user, but in the INTERNAL-ERROR case the
runner is always restarted, just like EXTERNAL-TIMEOUT, since we
assume that the internal state is compromised somehow.
--
wpt-commits: 6736e3f46bc6a110e6e550711208e492f1630eba
wpt-pr: 10444
Automatic update from web-platform-testsCSS: Remove support for position values with 3 parts
Intent:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/oBKMVCOX1sY/BLsXXiukAgAJ
BUG=804187
Change-Id: I94e79b2b426250c521d0ebae1492571fde078f31
Reviewed-on: https://chromium-review.googlesource.com/1013459
Reviewed-by: Emil A Eklund <eae@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550915}
--
wpt-commits: ff4cf69b8f1d705039d71ceef94dee04e74b35c9
wpt-pr: 10469
Automatic update from web-platform-testsReland "Web Animations: Fix bugs in procedure to process a keyframes argument"
This is a reland of 0ade0386aa4168b48234bc7f33d30a62140b95ea
Original change's description:
> Web Animations: Fix bugs in procedure to process a keyframes argument
>
> There were three minor bugs left in the implementation:
>
> - We threw on lists-in-custom-iterators instead of just ignoring them.
> - We returned all properties on the keyframe rather than just those
> defined on the keyframe itself (e.g. we would include prototype
> properties, against spec).
> - We didn't access the properties in ascending unicode order.
>
> Bug: 827573
> Change-Id: I213ae5b24e1f35d7f28d16625025122950a6ba88
> Reviewed-on: https://chromium-review.googlesource.com/989261
> Reviewed-by: Kentaro Hara <haraken@chromium.org>
> Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#550641}
Bug: 827573
Change-Id: I6c49fa6ca36db16ecddfb520e0964bd231565a0b
Reviewed-on: https://chromium-review.googlesource.com/1012897
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550895}
--
wpt-commits: da5837af9586234669a556c65fab521130688225
wpt-pr: 10465
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
Automatic update from web-platform-testsRevert "Web Animations: Fix bugs in procedure to process a keyframes argument"
This reverts commit 0ade0386aa4168b48234bc7f33d30a62140b95ea.
Reason for revert:
Unexpected Failures:
* bindings/sequence-type.html
* custom-elements/spec/define-element.html
* external/wpt/custom-elements/CustomElementRegistry.html
on
https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Mac10.11%20%28dbg%29/https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Linux%20Trusty%20%28dbg%29/
Speculatively reverting this to see if it's the cause.
Original change's description:
> Web Animations: Fix bugs in procedure to process a keyframes argument
>
> There were three minor bugs left in the implementation:
>
> - We threw on lists-in-custom-iterators instead of just ignoring them.
> - We returned all properties on the keyframe rather than just those
> defined on the keyframe itself (e.g. we would include prototype
> properties, against spec).
> - We didn't access the properties in ascending unicode order.
>
> Bug: 827573
> Change-Id: I213ae5b24e1f35d7f28d16625025122950a6ba88
> Reviewed-on: https://chromium-review.googlesource.com/989261
> Reviewed-by: Kentaro Hara <haraken@chromium.org>
> Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#550641}
TBR=flackr@chromium.org,yukishiino@chromium.org,jbroman@chromium.org,haraken@chromium.org,smcgruer@chromium.org
Change-Id: I5e8dc0c67599492bd6e90fca4a034e29e334ef88
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 827573
Reviewed-on: https://chromium-review.googlesource.com/1012857
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550721}
--
wpt-commits: cb845c5ab5e3c718f6de85ec6ac285770b9b394f
wpt-pr: 10464
Automatic update from web-platform-testsTest that requestMediaKeySystemAccess sets label (#8508)
On Edge, navigator.requestMediaKeySystemAccess ignores the value passed along to the label configuration field. This test exposes that bug.
See https://goo.gl/6SgCRb
--
wpt-commits: e6cffaa6d307ec6ef08102aad9c7a4a1df5b7d53
wpt-pr: 8508
Automatic update from web-platform-testsRevert "Reland: Use PostTask to schedule cross-process postMessage forwarding."
This reverts commit 7c3d1d13f940e88ef6706fd8b5c257a81d340ed9.
Reason for revert: WebviewLoginTest.Basic is still flaky on linux-chromeos-rel
https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-rel/6886https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-rel/6887
Original change's description:
> 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}
TBR=xiyuan@chromium.org,dcheng@chromium.org,alexmos@chromium.org
Change-Id: Ic0637a6038bed6e5334a26e1934bee81faad3b9e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 828529
Reviewed-on: https://chromium-review.googlesource.com/1012138
Reviewed-by: Ben Pastene <bpastene@chromium.org>
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550649}
--
wpt-commits: 6ad1b51de7dce0d45d08cc0f47a92a7b1fed69d2
wpt-pr: 10463
Automatic update from web-platform-testsWeb Animations: Fix bugs in procedure to process a keyframes argument
There were three minor bugs left in the implementation:
- We threw on lists-in-custom-iterators instead of just ignoring them.
- We returned all properties on the keyframe rather than just those
defined on the keyframe itself (e.g. we would include prototype
properties, against spec).
- We didn't access the properties in ascending unicode order.
Bug: 827573
Change-Id: I213ae5b24e1f35d7f28d16625025122950a6ba88
Reviewed-on: https://chromium-review.googlesource.com/989261
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550641}
--
wpt-commits: 2707869d65f3a4d5a1f2ab1d44920b19695a7cde
wpt-pr: 10399
Automatic update from web-platform-testsMerge pull request #10462 from ewilligers/background-serialization-variety
Accept variation in serialization of 'background'
--
wpt-commits: 1e5a5fefe15c4fcc1a3267daf1d75598f736c82f
wpt-pr: 10462
Automatic update from web-platform-testsReland: 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}
--
wpt-commits: f281334c36847064b75740239882e2684aee0437
wpt-pr: 10456
Automatic update from web-platform-testsAllow feature policy to be used in opaque origins.
Currently, policy-controlled features do not work as expected in
frames with opaque origins, such as isolated sandboxes and data: URLs,
because the eventual opaque origin of the frame is not known when the
HTMLFrameOwnerElement builds the container policy, and so has no way
to tell the browser that a particular origin should be allowed.
This CL adds a new member to the ParsedFeaturePolicyDeclaration, which
indicates that the iframe policy is expected to apply to the origin of
the frame, and is used when that frame has an opaque origin. This can
be triggered with an iframe of the form
<iframe sandbox allow="feature">
or
<iframe sandbox allow="feature src">
This flag is checked when building the feature policy in the new frame,
and ensures that the new feature policy will allow the feature in that
origin.
This is the first part of the eventual solution -- currently this has
the effect of allowing the feature even if a sandboxed frame navigates
to a new page (causing a new opaque origin to be created for it).
Subsequent CLs will add a unique identified to each such origin, and
ensure that the generated policies are properly tied to the specific
origin of the frame.
Bug: 690520
Change-Id: Ie18b9bc3c36be6550baf5a03e355871b9589fd40
Reviewed-on: https://chromium-review.googlesource.com/963382
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Ian Clelland <iclelland@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550463}
--
wpt-commits: 4c8580c189ce4501997af80b599bea070b1a7299
wpt-pr: 10076
Automatic update from web-platform-tests[css-typed-om] Support offset-rotate.
Introduces the <angle> data type.
Test fails because we compute offset-rotate to a pair rather than
'as specified'
had to rebaseline all the tests.
Bug: 820299
Change-Id: Ifdc192550b0b544b9887af80c259b3bfeede556b
Reviewed-on: https://chromium-review.googlesource.com/1003433
Commit-Queue: Darren Shen <shend@chromium.org>
Reviewed-by: nainar <nainar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550146}
--
wpt-commits: 1dd03e794199f6430072ecef144991112136cca5
wpt-pr: 10390
Automatic update from web-platform-testsFix race in track-stats.https.html test.
This resolves the onIceConnectionStateComplete probmise when
iceConnectionState reaches either 'connected' or 'completed' and fixes
the race if it had already reached these states before the function was
called.
This fix is speculative. I am no longer able to repro the TIMEOUT
locally with or without the fix.
Bug: 829401
Change-Id: I1dec90250d640d93498c59a932ab5e84a3b96f15
Reviewed-on: https://chromium-review.googlesource.com/1012029
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Commit-Queue: Henrik Boström <hbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550580}
--
wpt-commits: a4accccea67a4de543edebaa51aa8c8b898aa323
wpt-pr: 10458
Automatic update from web-platform-testsMerge pull request #10429 from emilio/mutation-record
[cssom] Add a test for mutation records when CSSStyleDeclaration.setPropertyValue is invoked.
--
wpt-commits: ab9fc1edc3f464617d6ed72a2336d064f9cdcfcc
wpt-pr: 10429
Automatic update from web-platform-tests[css-typed-om] Support remaining misc properties.
Known failures:
- all: computed value is always "", it should compute to something...
- animation-name: <custom-ident> not mentioned in typed om spec.
- cursor: 'grab' and 'grabbing' are still webkit prefixed.
- list-style-type: Blink implements something different to the spec.
- page: computed value is always "", <custom-ident> not mentioned in
typedom spec
- perspective: '0' seems to compute to none.
- perspective-origin: Blink doesn't support 'none' keyword
- quotes: computed value is always ""
- size: computed value is always ""
- speak: Blink implements something different to the spec.
- transform-box: Blink doesn't support 'border-box' keyword
- z-index: computed value is always 'auto' (might be something to do
with stacking context)
Bug: 820299
Change-Id: I629dda1c4bcac92f59cae3bddf11bd375f98e5c2
Reviewed-on: https://chromium-review.googlesource.com/1003434
Commit-Queue: Darren Shen <shend@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550527}
--
wpt-commits: 071e621564bc4af04a04e8b8e515bfb306a6613e
wpt-pr: 10391
Automatic update from web-platform-testsStringify RequestInit.body
As specified, RequestInit.body should be stringified, i.e.,
{toString(): () => 'hi!'} should be treated as same as 'hi!'.
Bug: 831076
Change-Id: I4118c0faa9535d62b3db2529bf23716fdc25a997
Reviewed-on: https://chromium-review.googlesource.com/1004561
Reviewed-by: Adam Rice <ricea@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Commit-Queue: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550523}
--
wpt-commits: 96bceca65945e50c61128eaf5473fc9bc9e46c99
wpt-pr: 10394
Automatic update from web-platform-testsRemove http/tests/w3c
This CL moves the final user-timing tests to external/wpt and removes
the folder. The performance_entrylist_checker is changed as in the http
counterpart to allow de-duplicating test messages.
There are some tests that are related to the wpt counterparts, but not
equivalent and in a different format, so unifying some of these tests
can be done in the future.
Bug: 498037
Change-Id: I6f35d962ba088d92a9768e49a65dea4d5c267491
Reviewed-on: https://chromium-review.googlesource.com/1007888
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550310}
--
wpt-commits: 51704839c172ba8a70910bff484837c25adbfc9a
wpt-pr: 10434
Automatic update from web-platform-testsUse version-specific prefs files when running Firefox (#10443)
Firefox requires a prefs file to be loaded to ensure that it doesn't
make external network connections, and to make sure that other
settings are appropriate for testing. Previously we always used the
version of the prefs file from master, which is usually fine for
nightly builds, but doesn't work with release builds if it happens
that a pref changed.
This change uses the correct release version of the prefs file for
firefox releases and beta versions. It continues to use the master
version for any nightly build; this could be fixed in some cases if we
are able to access the actual commit hash used to build Firefox, but
probably isn't too bad an approximation.
The caching algorithm was changed so that release versions of the
prefs are cached forever, and the nightly version is updated once per
day (although this doesn't quite match the nightly release cadence,
it's only going to fail in edge cases where the prefs were changed in
the file, but the nightly version was not yet updated, of vice-versa.)
--
wpt-commits: cf2ef62f1c470b47a03275c795c6dedd69eace88
wpt-pr: 10443
