Automatic update from web-platform-tests[css-properties-values-api] Invalidate paint worklet on registration.
Due to how initial values of registered custom properties used to be
handled, the style diff function for custom paint could not discover that
the computed value for some property changed due to a new property
registration.
This meant that, if you used the property '--x' in your paint worklet
(without applying '--x' on any element in the document), and _then_
registered the property '--x' (giving it an initial value), the worklet
would not repaint even though the computed value of --x changed from
"nothing" to the registered initial value.
Now that initial values are returned from ::GetRegisteredVariable, simply
compare those values when diffing for custom paint invalidation.
Note that the second test in this CL is already passing before this CL,
but I'm including it anyway since that case is also mentioned in the bug.
R=ikilpatrick@chromium.org
Bug: 657706
Change-Id: I2b7707d48d73693a70b100fe1121bd7f977b4db1
Reviewed-on: https://chromium-review.googlesource.com/c/1309788
Commit-Queue: Anders Ruud <andruud@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604607}
--
wpt-commits: 2a5673603f719fed9b3dce2f6bde705057b90599
wpt-pr: 13822
Automatic update from web-platform-testsMake Element#innerText not to emit Tab/Newline for <td>/<tr>/<br> itself
This patch changes |Element#innerText| not to emit Tab/Newline for <td>, <br>,
<tr> itself to follow the spec change[1] for improving interop.
Example:
- <br>.innerText -> "" (was "\n")
- <td>abc</td>.innerText -> "abc" (was "abc\t")
- <tr><td>abc</td></tr>.innerText -> "abc" (was "abc\n")
[1] https://github.com/whatwg/html/pull/4132 Make innerText getter not run the
algorithm on the element itself
Bug: 897373
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I4266ee28df9b44e9044dfa60c2d54257a5f82eeb
Reviewed-on: https://chromium-review.googlesource.com/c/1312436
Reviewed-by: Yoichi Osato <yoichio@chromium.org>
Commit-Queue: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604872}
--
wpt-commits: ff0b6d883e558c94a2302985d424606a80ed5200
wpt-pr: 13835
Automatic update from web-platform-tests[css-text] word-break:break-all does not affect punctuation (#13415)
Turns into an proper wpt test case the test discussed in https://github.com/w3c/csswg-drafts/issues/785#issuecomment-374866706
--
wpt-commits: b61f5da2f084542d060e954209a4794f346c789a
wpt-pr: 13415
Automatic update from web-platform-tests[css-text] word-break:keep-all with U+3000 (space) and U+3001 (punctuation) (#13211)
At the time of writing, Chrome passes, but Firefox and Safari fail.
Related to https://github.com/w3c/csswg-drafts/issues/3142
--
wpt-commits: ac65f580b18722c161a59fe1a4436f17f6acda2d
wpt-pr: 13211
Automatic update from web-platform-tests[css-overscroll-behavior] Inheritance, initial (#13677)
Properties inherit or not according to the spec.
Properties have initial values according to the spec.
https://drafts.csswg.org/css-overscroll-behavior/#property-index
--
wpt-commits: 69a295238d917c2438c0029a143757a99768f275
wpt-pr: 13677
Automatic update from web-platform-testslocation.pathname should return "blank" when there is no browsing context (#13854)
The pathname of "about:blank" is "blank", not "".
--
wpt-commits: a6322a0bf9f7b0553dec4c8eee5a673fccf9a91b
wpt-pr: 13854
Automatic update from web-platform-tests[Presentation API] Remove from insecure contexts.
This patch removes the Presentation API from insecure contexts. The number of presentations started on insecure contexts is 0.0001% of page views on desktop and 0.0004 on Android.
In addition it updates layout tests and WPT to use https: for presentation URLs.
Blink-dev thread:
https://groups.google.com/a/chromium.org/d/topic/blink-dev/lumj0lVdtHA/discussion
chromestatus.com feature entry:
https://www.chromestatus.com/feature/5766218384408576
Bug: 733381
Change-Id: I9ae3025160b0e0bcf987fda0068a0e6bd92c24fd
Reviewed-on: https://chromium-review.googlesource.com/c/1306336
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Commit-Queue: mark a. foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604621}
--
wpt-commits: 68c63e96b88dfaceb492a8247ea8830484bf8007
wpt-pr: 13794
Automatic update from web-platform-testsFix link markup in signed-exchange/README.md (#13790)
--
wpt-commits: 088f63b9c303e1e3a5be74058c0b81a5d30502f2
wpt-pr: 13790
Automatic update from web-platform-tests[css-properties-values-api] Store initial variables on ComputedStyle.
Initial values are currently not stored at all on ComputedStyle, and we
must refer to the PropertyRegistration to figure out what the initial value
for a given property is.
The problem with this, is that registering a property also has the effect
of giving all styles that are already computed new values (effectively).
For example, if a property '--x' is not registered (and not applied on any
style), the computed value of that property is the "empty value" as
described in css-variables. If the property then becomes registered,
the initial value suddenly becomes whatever is specified by the
registration, even on the ComputedStyle objects that already exist.
This causes problems for calculating transitions, because we incorrectly
consider the previous computed value to be "initialValue" from the
registration rather than what it really was: "empty value".
This CL adds a StyleInitialData class which contains the initial values
for all registered variables. This class is instantiated for the initial
style, and then referenced by all ComputedStyles that inherit from that
style.
This makes it possible to know what the initial value was for a certain
property at the time style calculation took place.
R=futhark@chromium.org
Bug: 848250
Change-Id: I0a44e06608738aab15cb35fbc448a47188932600
Reviewed-on: https://chromium-review.googlesource.com/c/1309736
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604580}
--
wpt-commits: bce35cc67fe84021df94dc52e60522b1f1b46e8b
wpt-pr: 13816
Automatic update from web-platform-testsAdd extra utilities to content::media_constraints
This CL adds:
* NumericRangeSet::Contains().
* NumericRangeSet::EmptySet().
* ResolutionSet::FromNativeResolution().
These utilities are in preparation for supporting the resizeMode
constrainable property in getUserMedia() and applyConstraints().
Drive-by: minor fixes/improvements.
Bug: 854980
Change-Id: I858f406308aa9bba40521d5e740219b72e2c8a48
Reviewed-on: https://chromium-review.googlesource.com/c/1308133
Reviewed-by: Henrik Boström <hbos@chromium.org>
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604574}
--
wpt-commits: 5b699ddb3200ce3abc8a2a5059c52235076bde4f
wpt-pr: 13845
Automatic update from web-platform-tests[Azure Pipelines] Split manifest update into a separate step (#13831)
For some reason, manifest generation is faster this way.
Drive-by: don't use multi-line script where not needed
--
wpt-commits: 46e12063c39422833ea51552e86b200175be0f1a
wpt-pr: 13831
Automatic update from web-platform-testsAdd support for resizeMode in MediaStreamTrack.getSettings()
This CL exposes the current resizeMode setting to the Web Platform.
As of this CL, the resizeMode is 'none' if the track resolution
corresponds to the native resolution of the video source, without any
resolution adjustment. It is 'crop-and-rescale' if rescaling is
necessary.
The resizeMode currently cannot be set explicitly with getUserMedia() or
applyConstraints(), but this functionality will be added in a follow-up
CL.
Drive-by: Add separate WPT tests for all getSettings() properties.
Intent to Ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/V2srjdzRCXE
Bug: 854980
Change-Id: Id4c683e6b2f228b17cf2354cb7fc589ca9e593a6
Reviewed-on: https://chromium-review.googlesource.com/c/1307448
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Henrik Boström <hbos@chromium.org>
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604562}
--
wpt-commits: dcf7730d7300f236459aa20990e14d46f3517916
wpt-pr: 13840
Automatic update from web-platform-tests[css-animations] animation-duration computed value (#13819)
Durations are serialized in seconds.
https://drafts.csswg.org/css-values-4/#time
--
wpt-commits: e92093981dfdba5154fd8c41021f2bf99751e67b
wpt-pr: 13819
Automatic update from web-platform-testsUpdate selenium from 3.14.1 to 3.141.0
--
Update selenium from 3.14.1 to 3.141.0
--
Update selenium from 3.14.1 to 3.141.0
--
Update selenium from 3.14.1 to 3.141.0
--
Update selenium from 3.14.1 to 3.141.0
--
Update selenium from 3.14.1 to 3.141.0
--
Update selenium from 3.14.1 to 3.141.0
--
wpt-commits: 48af82969fefb8d2fe80f8b0e6162dd707bec073, 0caf7b0df499a1a80c582a0aa876f95298bf9563, f6077c770a969300b730e460b0ef6f5164257f93, 4b0226dd1adc95ee1cc50df66fb79f85dc8e05c1, 7f2e42aaa0305df82b2c9094cbfcb1a9c459bce6, 2c4f1aee95cf4878c7644803e25ffb385101a7dc, 751803fa80e835e4afa55f69cc8e87c86a8aaadd
wpt-pr: 13839
Automatic update from web-platform-testsXMLHttpRequest: overrideMimeType and workers
See https://bugzilla.mozilla.org/show_bug.cgi?id=723739 for context.
--
wpt-commits: 046815564b1808dddb4898b18e88607bb52aa13d
wpt-pr: 12181
Automatic update from web-platform-tests[layoutng] Fix setting of fixed_block_is_definite
When a flex item has a definite specified height (e.g. height: 100px),
then percentages in children of the flex item should resolve even
if the flexbox does not have an explicit height, ie. does not match
the condition in https://drafts.csswg.org/css-flexbox/#definite-sizes
Bug: 885185
Change-Id: Iba226f30e1e02e3a11273fa45fcdf1cef897120c
Reviewed-on: https://chromium-review.googlesource.com/c/1311534
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604483}
--
wpt-commits: d77d5561cda3ab330143bdd5fed7a96b84be24e0
wpt-pr: 13829
Automatic update from web-platform-testsNo vertical bars if 'vertical-policy' disabled
When 'vertical-scroll' policy is disabled in a document, the contents
cannot be scrolled (will not be user-input scrollable and targeted
for gesture scroll). However, currently disabling 'vertical-scroll'
still leaves the vertical scrollbars behind; the bars position cannot
be changed however.
This CL fixes the issue by hiding the vertical scrollbars for
scrollable elements inside documents where the policy is enforced
(i.e., disabled).
Bug: 898151
Change-Id: If01925e27184a7370d5b12583dc73bc946f2c6e2
Reviewed-on: https://chromium-review.googlesource.com/c/1305878
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604420}
--
wpt-commits: 8295368c82194ac6c1443571bdd57b464bfc55b4
wpt-pr: 13824
moz-wptsync-bot
YUHAN WU
Anders Hartvoll Ruud
Yoshifumi Inoue
Florian Rivoal
Anne van Kesteren
Dominic Farolino
Eric Willigers
Marcos Cáceres
Chris Dumez
mark a. foltz
Philip Jägenstedt
Guido Urdaneta
Wanming Lin
pyup-bot
HyeockJinKim
autofoolip
Christian Biesinger
Ehsan Karamad