This check was originally added for tracking protection, and we need to keep
the state of the document updated for the rest of our blocking states even
for third-party channels.
Differential Revision: https://phabricator.services.mozilla.com/D6596
It is arguably more accurate to implement these boolean
getters in terms of whether we remember blocking anything
in the category being asked about. This will allow us to
correctly account for hiding the sheild icon when all
currently blocked trackers become unblocked, for example.
Differential Revision: https://phabricator.services.mozilla.com/D6600
This check was originally added for tracking protection, and we need to keep
the state of the document updated for the rest of our blocking states even
for third-party channels.
Differential Revision: https://phabricator.services.mozilla.com/D6596
The assumption is that there aren't many webpages that are currently using web
components yet so we may want to take advantage of lazily loading the
SlottedNodeContainer.
Automatic update from web-platform-testsAdd headless mode for chrome_webdriver (#13201)
0200c63a74a540dfb870881d5f476280c367d1c1 failed to add this to
chrome_webdriver, so add this now.
--
wpt-commits: 1e7408fcd394b66234c38c24ba044ec6f00e4b70
wpt-pr: 13201
Automatic update from web-platform-tests[css-properties-values-api] Substitution behavior.
Currently, registered properties substitute into other values exactly
like specified (like unregistered properties). This means that, for
a <length>-registered property with a specified value "10em" (for
instance), when that property is substituted via var()-reference,
the tokens "10em" are inserted. This is not correct, and produces the
wrong result with e.g. inherited values.
This CL changes that, by implementing "absolutization" of registered
custom properties: a process which calculates the computed value of
the property, and then produces a token stream usable for substitution
which is equivalent to the computed value.
* Currently we resolve var()-references on all custom properties
before applying high-priority properties. This is no longer
possible, because the true value of a custom property (also
unregistered) can not be known until the font has been updated.
Consider: --reg-len: 1em; --unreg:var(--reg-len). Here, the
computed value of --unreg should be "16px" (assuming a font-size
of 16px), and not "1em". If we destructively resolve --unreg
before the font size is known, we end up with the wrong tokens.
Hence the resolution process has been moved to after the font
has been updated.
* Custom properties must also be usable from high-priority properties.
Since they are no longer resolved beforehand, they are resolved
"on the fly", non-destructively. "Non-destructively" means that
resolved token streams are not stored on ComputedStyle, such that
any var()-references are kept for the _real_ resolution pass after
the font has been updated.
This works, because the high-priority properties do not require
proper "absolute substitution" to produce the correct value.
Note that font-size is special, in that font-relative units may
not be used if they arrive via a registered custom property.
* There is a special resolving pass for registered custom properties
(ComputeRegisteredVariables). This pass produces non-absolute CSSValues
for calculation of animation.
* Parsing of registered properties now happens entirely in
CSSVariableResolver, and no longer in variable.cc. Having this in
multiple places is just confusing.
R=futhark@chromium.org
Bug: 641877
Change-Id: Ic705d0808ffcea0ae5db02fb20870767175bb706
Reviewed-on: https://chromium-review.googlesource.com/1240274
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593902}
--
wpt-commits: c801e269e3e22d11e1bb4530ff15e87db877b1d2
wpt-pr: 13193
Ehsan Akhgari
Noemi Erli
J.C. Jones
Gabriel Luong
Jim Chen
Kartikaya Gupta
Marco Castelluccio
Andreea Pavel
Dão Gottwald
moz-wptsync-bot
Geoffrey Sneddon
Anders Hartvoll Ruud