Automatic update from web-platform-testsMove the config into its own class (#10231)
--
wpt-commits: bfef1f20a419d24633e48d24c14e6a7503e1d48c
wpt-pr: 10231
wpt-commits: bfef1f20a419d24633e48d24c14e6a7503e1d48c
wpt-pr: 10231
The (fast) internal reftest runner wasn't affected by this, so we
didn't notice the breakage since it only happened on platforms still
using the older broken runner.
MozReview-Commit-ID: AA2GOspOxgR
No cleaner ideas right now that carrying that counter around... Maybe a custom
type may be cleaner?
This makes ApplicableDeclarationBlock a bit bigger. I could probably try to make
the counter a 4 / 5-bit number or something and pack the counter there in the
SourceOrderAndCascadeLevel somehow...
But doesn't seem really worth the churn, and can be done as a followup in any
case. Let me know if you want to block on that.
MozReview-Commit-ID: 1LdW9S4xA6f
Automatic update from web-platform-testsCorrectly reject in-progress body methods with AbortError
Prior to this change, response body methods such as
response.body.arrayBuffer() would reject with a TypeError if the fetch
was aborted. This change makes them correctly reject with an AbortError
instead.
This implements stage #3 of the "Body Cancellation" section of the
design doc:
https://docs.google.com/document/d/1OuoCG2uiijbAwbCw9jaS7tHEO0LBO_4gMNio1ox0qlY/edit#heading=h.fvc7d7q07oio
Bug: 817687
Change-Id: Ifde322d9c22485a8ba9d14fd4ffca65c4fb4745a
Reviewed-on: https://chromium-review.googlesource.com/954765
Commit-Queue: Adam Rice <ricea@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544335}
wpt-commits: f2ae7641fad03150b4238a8b34dc9bdfdf58c0dd
wpt-pr: 10096
wpt-commits: f2ae7641fad03150b4238a8b34dc9bdfdf58c0dd
wpt-pr: 10096
MozReview-Commit-ID: KWIBtaWMUPx
This also adopts the resolution of [1] while at it, and switches XUL to not
support display: contents until a use case appears.
This makes our behavior consistent both with the spec and also in terms of
handling dynamic changes to stuff that would otherwise get suppressed.
Also makes us consistent with both Blink and WebKit in terms of computed style.
We were the only ones respecting "behaves as display: none" without actually
computing to display: none. Will file a spec issue to get that changed.
It also makes us match Blink and WebKit in terms of respecting display: contents
before other suppressions, see the reftest which I didn't write as a WPT
(because there's no spec supporting neither that or the opposite of what we do),
where a <g> element respects display: contents even though if it had any other
kind of display value we'd suppress the frame for it and all the descendants
since it's an SVG element in a non-SVG subtree.
Also, this removes the page-break bit from the display: contents loop, which I
think is harmless.
As long as the tests under style are based in namespace id / node name /
traversal parent, this should not make style sharing go wrong in any way, since
that's the first style sharing check we do at [2].
The general idea under this change is making all nodes with computed style of
display: contents actually honor it. Otherwise there's no way of making the
setup sound except re-introducing something similar to all the state tracking
removed in bug 1303605.
[1]: https://github.com/w3c/csswg-drafts/issues/2167
[2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700
MozReview-Commit-ID: JoCKnGYEleD
This is regression of bug 1423835.
When I fixed the bug, I accidentally changed the result of
HTMLEditRules::JoinNodesSmart() to use new API. However, it was simple
misunderstand. The original code sets the initial value of result to
{ aRightNode - aLeftNode.Length() } but I understood it as
{ aRightNode - aRightNode.Length() }. Therefore, this patch backs out the
patch only for this line.
MozReview-Commit-ID: 5rD7YFij8v
--HG--
extra : rebase_source : c11770892ab7416b9bf5d3329fc8b7b413387747
If the content process crashes, marionette can return None rather
than a valid result. In this case we want the test status to end up
as crash, which happens if we just propogate the None upwards.
Automatic update from web-platform-testsAdd tests for Event.srcElement
See https://github.com/whatwg/dom/issues/625 for details.
--
Add tests for Event.returnValue
See https://github.com/whatwg/dom/issues/625 for details.
wpt-commits: 13597c4af7ac923309e740920cd42bed88113e5f, 24f49ff15e22f7d81dbb87908efa0b5970b7add6
wpt-pr: 10258
wpt-commits: 13597c4af7ac923309e740920cd42bed88113e5f, 24f49ff15e22f7d81dbb87908efa0b5970b7add6
wpt-pr: 10258
Automatic update from web-platform-testsAvoid async/await in /webstorage/idlharness.html
Am sorry, Servo is dumb, we are actively trying to fix that on our side.
wpt-commits: 95992cd324d80acc68707b203be8c6cc2aebc6d5
wpt-pr: 10357
wpt-commits: 95992cd324d80acc68707b203be8c6cc2aebc6d5
wpt-pr: 10357
Automatic update from web-platform-testsservice worker: Add tests for inteception of workers after redirects.
This tests behavior discussed here:
https://github.com/w3c/ServiceWorker/issues/1289
Namely it tests when a request for a worker goes through a redirect
chain:
1) On redirect from A -> B, whether the service worker at B
sees the request.
2) After the final redirect, which service worker controls the
resulting client.
The tests are written as specified today. Therefore, Firefox
passes this test (verified in Nightly) and Chrome does not.
(Actually a small change is required to the test to make Firefox
pass it, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1452528)
Currently it only tests shared worker but dedicated worker can
be added in a follow-up patch.
Bug: 829720
Change-Id: Id3b1ea8b952760be0ef9917f2c6a3afe60ca1fb5
Reviewed-on: https://chromium-review.googlesource.com/999241
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549125}
wpt-commits: 6fe36d79072d5261ea504435b0dfedaf39f5805a
wpt-pr: 10340
wpt-commits: 6fe36d79072d5261ea504435b0dfedaf39f5805a
wpt-pr: 10340
Automatic update from web-platform-testsCorrect serialization of box-shadow and text-shadow
Following https://github.com/w3c/csswg-drafts/issues/2305, the canonical serialization for box-shadow was changed to the color then lengths. https://drafts.csswg.org/css-text-decor-3/#text-shadow-property also defines the canonical serialization for text-shadow as the color and then lengths. This caused the test to fail in Firefox, Chrome, and Safari. Update the test to match the spec in both instances.
wpt-commits: a835486e59a94236a55107fe34925079b33ef247
wpt-pr: 9800
wpt-commits: a835486e59a94236a55107fe34925079b33ef247
wpt-pr: 9800
