I forgot we were doing this "revert-or-initial" shenanigans (which is needed
for stuff like link colors to be honored), so we need to early-return.
Use a more explicit test rather than a reftest for this.
Differential Revision: https://phabricator.services.mozilla.com/D142063
They are just convenience for :root[lwthemetextcolor="light"] (and dark,
respectively), but they generally shouldn't be used for dark mode
theming. In the past it was the only way to do it but now we have
prefers-color-scheme.
While at it, change lwthemetextcolor to be "lwtheme-brighttext" for
consistency with similar code we have for popups etc, and move it to
_setDarkModeAttributes.
While at it, remove layout.css.moz-lwtheme.content.enabled (which is
false always, we unshipped these from content successfully).
Differential Revision: https://phabricator.services.mozilla.com/D141593
The flags stylo cares about reading and writing potentially at the same
time are disjoint, so there's no need for any strong memory ordering.
Differential Revision: https://phabricator.services.mozilla.com/D141829
The flags stylo cares about reading and writing potentially at the same
time are disjoint, so there's no need for any strong memory ordering.
Differential Revision: https://phabricator.services.mozilla.com/D141829
This should be cheap and gives us a lot of memory savings for the page
on the bug, by deduplicating the inherited properties between parent and
children.
WebKit implements a similar optimization.
Differential Revision: https://phabricator.services.mozilla.com/D140826
If a name is not in self.seen, it means we've inherited it from our
parent. That in turn means that it can't have any variable reference
(because we inherit the computed variables) and we can skip the work of
traversing it, as we'd hit the early-return in traverse() anyways.
This doesn't fix the memory usage issue of the page on the bug, which
has a giant list of properties on the root and then a custom property
specified on all elements, but should significantly reduce the time we
spend iterating over custom properties for all those elements.
Differential Revision: https://phabricator.services.mozilla.com/D140825
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
If the theme is dark but user prefers light pages, the background of the
tabpanel should arguably be light, since it can be seen across some
navigations.
Expose a -moz-content-prefers-color-scheme media query to chrome pages
so that our UI can correctly query it (and remove the unused -moz-proton
atom while at it).
Differential Revision: https://phabricator.services.mozilla.com/D136437
The issue here is that we end up with a transition between mismatched
transform lists that ends up generating an InterpolateMatrix {}
operation. So far so good, but we end up interpolating that a lot of
times and generating an unboundedly-deep operation list.
This implementas an optimization that flattens them to a single matrix
when possible (when there's no dependencies on the containing box).
This is similar to:
2b89cc4df4
We fix the to_pixel_length() behavior for LenghtPercentage to be
correct (and update callers to preserve behavior).
Differential Revision: https://phabricator.services.mozilla.com/D134784
Hashbrown grows a lot sometimes making us waste a lot of memory. Shrink
some of these maps after CascadeData rebuild / stylesheet collection
invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D134716
The only remaining consumers are ::-moz-tree pseudo-elements (we used to
use ThinBoxedSlice for other data structures in the past).
Those are not particularly performance sensitive so I think just
double-boxing is fine. In the future, if we wanted to avoid the double
indirection, we could probably use the "thin" crate
(https://docs.rs/thin) or similar, which stores the length of the slice
along with the allocation, making the pointer thin in all
configurations, much like "ThinArc" does:
https://searchfox.org/mozilla-central/rev/1ce2eea39442190a71a1f8f650d098f286bf4a01/servo/components/servo_arc/lib.rs#891
In practice though, I don't think it's particularly worth it for this
specific case.
Differential Revision: https://phabricator.services.mozilla.com/D134672
