This fixes a rather subtle bug. What the underlying code here is trying
to do is remove nsChangeHint_UpdateContainingBlock when some properties
that influence whether a frame is a containing block for absolutely
positioned or fixed positioned elements have changed, but the final
calculation of being a containing block has not changed. However, the
old code was using a function that tested whether the style could
*possibly* lead to a frame being a containing block. Some of the
properties (like the transform properties) that lead to being a
containing block, for example, don't apply to non-replaced inlines.
Some, however, do (such as 'filter'). So if there's a dynamic change
adding or removing a filter, on an inline that also has an *ignored*
transform property (like 'transform' or 'perspective') set, then the
code prior to this patch causes us to remove the UpdateContainingBlock
hint.
This patch fixes things by testing whether being a containing block
could have changed for *any* type of frame, by separately testing the
changes.
The added tests fail without the patch and pass with the patch, viewed
in isolation. However, without the previous patch, test 003 passes.
Test 003 also fails in Chrome (but 001 and 002 pass).
Differential Revision: https://phabricator.services.mozilla.com/D2814
--HG--
extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
The basic change here is making nsCSSFrameConstructor::ConstructInline
use the function nsIFrame::IsAbsPosContainingBlock rather than testing
for only one of the conditions in it (being relatively or absolutely
positioned). The rest of the code changes follow from that change.
I tested locally that the added test fails without the patch and passes
with it (either with or without the next patch).
Note that this causes a regression of three web-platform-test reftests:
testing/web-platform/tests/css/css-contain/contain-paint-002.html
testing/web-platform/tests/css/css-contain/contain-paint-011.html
testing/web-platform/tests/css/css-contain/contain-paint-012.html
which will be fixed in patch 4, since that fix is easier to write after
patch 2.
Differential Revision: https://phabricator.services.mozilla.com/D2813
--HG--
extra : rebase_source : 0d374628207c234bcd7cf4e320188994fc2680b8
At the moment, a tag that has document type capabilities will try to
load tag content with invalid MIME types as a document. This patch
will cause the load to fail silently instead.
This will cause failures in certain WPTs that expect plugins to be
present to fill in MIME type requirements, which we currently don't
have available on CI. These WPTs have been disabled for the moment.
MozReview-Commit-ID: 9JGR4LClE5x
Differential Revision: https://phabricator.services.mozilla.com/D2542
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-testsAdd a default name ("idl_test setup") for idl_test (#12276)
--
wpt-commits: 70413d8d6bf4bf581e52bc3a5edddd205fbd7a41
wpt-pr: 12276
Automatic update from web-platform-tests[idlharness.js] Catch IdlArray.test bugs better (#12272)
When a bug exists in `IdlArray.test`, `idl_test`'s `catch` flow is incorrectly re-attempting to run the tests (causing a double-up of the tests). See https://github.com/web-platform-tests/wpt/issues/11700.
This changes the flow to call `IdlArray.test` in a `finally` (regardless of whether any setup errors have occurred), preventing the possibility of double-ups when bugs in `IdlArray.test` occur.
Also fixes the bug that highlighted this problem (passing a `null` object when the interface contains a `toJSON` operation).
--
wpt-commits: e9f3244421c353a63142dd9742e0ed6edc509cc8
wpt-pr: 12272
Automatic update from web-platform-testsURL: additional tests for URLSearchParams's sort()
This adds the following tests for:
* Parameter names with more than one character.
* Parameter names with identical characters, but differing lengths.
* Parameter names that are the empty string.
* Parameter names that contain characters with the same number of code units.
--
wpt-commits: 7cee0d238c42272d48fd06935c5abcf1e490b394
wpt-pr: 12248
Automatic update from web-platform-testsUpdate buffered amount when async callbacks are called
If an asynchronous callback is called, it means we must have returned to
the start of the event loop. Ensure that any consumed bufferedAmount is
reflected in that case. Do not reflect bufferedAmount if the EventQueue
is paused, as that means that we may be in a nested event loop.
Add a unit test for this case. Also add a unit test for normal
bufferedAmount behaviour, as there wasn't one.
Add a web platform test for what happens if a sync XHR is performed
between calling send() and looking at bufferedAmount.
BUG=856651
Change-Id: Iafa2d619a1eb5284b64500ac03d336fb6380193b
Reviewed-on: https://chromium-review.googlesource.com/1151086
Commit-Queue: Adam Rice <ricea@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580078}
--
wpt-commits: 80f89c9af6cda0d80faf7f9b1c487eaff7205059
wpt-pr: 12198
Automatic update from web-platform-testsUpdate ReadableStream to match standard
Apply standard changes to ReadableStream up to standard version
51227372cc84846bdcf68312724c4cac6a4b9e58. With this change, Blink's
implementation once again passes all non-byte-stream ReadableStream
tests.
Update test expectations to match.
Changes:
* Use null prototypes for the objects returned by
ReadableStreamDefaultReaderRead when they consumed internally by
pipeTo(), tee() or fetch. This is the fix for standard issue
https://github.com/whatwg/streams/issues/933 "Setting
Object.prototype.then permits interfering with pipeTo() internals".
* In pipeTo() complete all pending writes when readable stream is
errored.
* Change ordering of accessing strategy parameters to match standard.
Non-user visible changes:
* Use Object.assign() to be more concise when modifying the binding
object in ReadableStream.js and WritableStream.js.
WPT changes:
* Update the expectations in response-stream-with-broken-then.any.js
since interference is no longer possible.
* Add extra tests to response-stream-with-broken-then.any.js for the
arraybuffer -> text case which should have been broken in Chrome but
wasn't, and the arraybuffer -> stream case.
* Fix bugs in streams/piping/then-interception.js which are only
apparent when it passes. In particular, delete Object.prototype.then
even when it is not called.
BUG=866388
Change-Id: I82c8ac2c2b7d71ccbf331388014e8cec847e1b65
Reviewed-on: https://chromium-review.googlesource.com/1149678
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Adam Rice <ricea@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580057}
--
wpt-commits: 4e98c23a16efc0eb6ea4c305e3f48def3cac4643
wpt-pr: 12178
Automatic update from web-platform-testsAdd tests for worker's URLs intercepted by ServiceWorker
This CL checks worker global scopes' URLs (self.location) in the
cases where worker top-level scripts are intercepted by
ServiceWorkers.
The test failure introduced in this CL will be fixed by
https://chromium-review.googlesource.com/1153598.
Bug: 861564
Change-Id: Ia92e1de697b5b9c6a61ab8e5c5abcaaf6dcee777
Reviewed-on: https://chromium-review.googlesource.com/1157220
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580041}
--
wpt-commits: aaaf24402c22c34f95c676f8392f2351a433842d
wpt-pr: 12250
Automatic update from web-platform-testsCookie Store API: Add test showing BOMs are not stripped
The cookie RFC[1] does not define an encoding for cookie names/values;
they are treated as a sequence of octets.
The Cookie Store spec[2] mandates treating the octets as UTF-8 encoded.
When decoding octet sequences into strings, the decode should be done
without treating a leading U+FEFF as a BOM. Add a test to verify this.
[1] https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02
[2] https://wicg.github.io/cookie-store/
Bug: 729800
Change-Id: I23b7eb82b35862b8797a203ae6ea86cbd69001d2
Reviewed-on: https://chromium-review.googlesource.com/1159336
Reviewed-by: Victor Costan <pwnall@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579985}
--
wpt-commits: 2c4d441493daa04906619978f4d1e9838d6b12d1
wpt-pr: 12264
Automatic update from web-platform-testsservodriver: Use config property instead of kwarg for browser kwargs.
--
wpt-commits: d769d0a84a3e6d941775fb2479f6457e9ddb8d36
wpt-pr: 12261
Automatic update from web-platform-testsFold "Unscopable handled correctly" tests into the attribute/operation tests (#12211)
The `[Unscopable]` checks were added here:
https://github.com/web-platform-tests/wpt/pull/9490
However, this extended attribute is very rarely used, currently only
in DOM and Fullscreen. And yet, every property and operation generates
a test like this, which is normally passing, example:
https://wpt.fyi/results/compat/interfaces.any.html
Just fold these into the existing tests for attributes/operations like
the many other aspects already covered. Because of the
"do_interface_attribute_asserts must be the last thing" problem,
there's a change of structure for the attribute test.
--
wpt-commits: 2f8b11a39d4da8d729903b1b30557a875d5bf76a
wpt-pr: 12211
