QualifiedRule::for_each_as_declaration_list() now takes a rule_name, so
that the error message can actually be useful - we only know what a
qualified rule is by context.
Instead of random dbgln_if(CSS_PARSER_DEBUG) messages, this lets us
report what kind of error it was. Repeated errors are combined instead
of spamming the console.
Ideally this would also record where the error occurred, but not yet.
PaintContext dates back to a time when display lists didn't exist and it
truly represented "paint context". Renaming it to better align with its
current role.
This parses `anchor-size(..)` functions in CSS, but does not yet result
in a useful `Size`: we need style & layout interleaving similar to
container queries for this, since the resulting value depends on layout
results.
Not supported yet: `anchor-size()` appearing inside a `calc()` node.
Adds 4280 WPT subtest passes in `css/css-anchor-position`.
This allows them to keep style sheets alive while loading fonts for
them. Fixes some GC crashes seen on the WPT WOFF2 tests after
66a19b8550 stopped FetchRecord leaks from
keeping various other things alive.
Before this change, whenever element's attributes changed, we would add
a flag to "pending invalidation", indicating that all descendants whose
style uses CSS custom properties needed to be recomputed. This resulted
in severe overinvalidation, because we would run invalidation regardless
of whether any custom property on affected element actually changed.
This change takes another approach, and now we decide whether
descendant's style needs to be recomputed based on whether ancestor's
style recomputation results in a change of custom properties, though
this approach adds a little overhead to style computation as now we have
to compare old vs new hashmap of custom properties.
This brings substantial improvement on discord and x.com where, before
this change, advantage of using invalidation sets was lost and we had
to recompute all descendants, because almost all of them use custom
properties.
Compare `Vector<Parser::ComponentValue>` directly instead of
serializing them into strings first.
This is required for the upcoming changes where we would compare
previous and new sets of custom properties to figure out whether we need
to invalidate descendant elements. Without this change `equals()` would
show up being hot in profiles.
This patch expands our generated content support beyond single strings
to lists of strings and/or images.
Pseudo-elements like ::before and ::after can now use content:url(...)
to insert anonymous image boxes into the layout tree.
This is heavily used in Google Docs for UI elements.
Having a setter for `device_pixels_per_css_pixel` was confusing because
display lists are immutable, so it doesn't make sense to override this
value after the display list has been created.
6507d23 introduced a bug when snapshot for iframe is saved in
`PaintNestedDisplayList` and, since display lists are immutable, it's
not possible to update before the next repaint.
This change fixes the issue by moving `ScrollStateSnapshot` for
nested display lists from `PaintNestedDisplayList` to
`HashMap<NonnullRefPtr<DisplayList>, ScrollStateSnapshot>` that is
placed into pending rendering task, making it possible to update
snapshots for all display lists before the next repaint.
This change doesn't have a test because it's really hard to make a ref
test that will specifically check scenario when scroll offset of an
iframe is advanced after display list is cached. We already have
`Tests/LibWeb/Ref/input/scroll-iframe.html` but unfortunately it did
not catch this bug.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/5486
This uses a `foo>bar` notation in the `valid-identifiers` field of
Properties.json, to say "replace `foo` with `bar`".
The motivation here is to avoid calling `parse_css_value_for_property()`
inside the per-property switch in `parse_css_value()`. Eventually we'll
need to be able to call that switch from
`parse_css_value_for_properties()` so that shorthands can make use of
any bespoke parsing code to parse their longhands.
Before this change, calc() would resolve to different types depending on
the nearest containing value context. This meant that rgb(calc(), ...)
by itself worked correctly due to fallbacks, but rgb(calc(), ...) inside
e.g a linear-gradient would create a calc() value that resolves to a
length, which subsequently got rejected by the color value parser.
Fixing this makes various little gradients show up on Discord.
At some point `hue-rotate` was changed to use `AngleOrCalculated`
rather than `Angle`, but `Angle` was still being used in a `visit`,
which otherwise defaulted to zero. This caused all `hue-rotate` angles
to serialize to zero.
Fixes bug when `build_matching_rule_set()` mistakenly included all
unlayered rules twice. This was caused by mistakenly including all
unlayered rules into `""` named "service" layer, because we couldn't
tell if FlyString = `""` means no layer or layer named `""`.
...for `text-justify: inter-character`.
We previously had this mapped in Enums.json, but the behaviour is
different: `a=b` in Enums.json keeps `a` around but makes it behave the
same as `b`. A legacy name alias is instead expected to replace `a`
with `b`, so we have to do that separately.
We don't yet have a system for "legacy value aliases", but until we have
a lot of them we can handle them manually.
We also have to do this in two places because
parse_css_value_for_property() doesn't call any property-specific
parsing code.
Before this change we were running the CSS cascade machinery twice per
element:
- First, to compute the "logical alias mapping context" based on
writing-mode and pals.
- Then, to compute all properties.
This patch factors out the heaviest work from the cascade machinery
to a separate step that can be run only once. This step will:
- Collect all the matching rules for the element
- Resolve custom properties for the element
We still perform the per-element cascade twice, but now this is hogging
less than 1% of CPU time when typing on Discord (compared to 9% before.)
...elements. Adds missing pseudo-element type passed into computed
properties getter.
Previously, due to this bug, we were using the element's computed
properties as the previous computed properties for its pseudo-elements.
This caused an excessive number of unintended CSS transitions to run.
The issue was particularly noticeable in Discord's emoji picker, where
each emoji has `::after` pseudo-element. We were incorrectly triggering
transitions on all their properties, resulting in significant
unnecessary work in style computation and animation event dispatching.
...and setter. We had lots of places where we check if pseudo-element
type is specified and then use `pseudo_element_computed_properties()` or
`computed_properties()`. This change moves these checks from caller side
to the getter and setter.
We now do the proper thing in terms of:
- Allowing percentages
- Returning the computed value in getComputedStyle
- Handling values out of the [0,1] range
Gains us 13 WPT passes in the imported tests.
