LibWeb: Invalidate an element with CSS custom props on attribute changes #3853
Conversation
|
Hello! One or more of the commit messages in this PR do not match the Ladybird code submission policy, please check the |
kmruiz
force-pushed
the
fix/render-document-after-parent-changes-class-with-css-vars
branch
5 times, most recently
from
8985c79 to
01f9c95
Compare
|
Your new test is timing out on all the CI actions that run it. Something is up. |
|
Yes, apologies! Just found out that the test was broken because it was testing for the colour name instead of the rgb(...) syntax. There was also a typo that was making the test throw an exception, which I guess made the CI timeout. This commit should fix it. |
|
Please squash the changes from the second commit into the first. PRs in this repository are merged by rebasing the individual commits on master. And each commit that ends up on master should be fully buildable have tests passing. Since your second commit fixes a problem with code introduced in the first commit, this is currently not the case. |
kmruiz
force-pushed
the
fix/render-document-after-parent-changes-class-with-css-vars
branch
from
07a2080 to
38138cf
Compare
|
Done. Squashed everything into a single commit. |
Element styles should be invalidated when they depend on CSS variables defined in one of their ancesors or when one of their ancestors change their class, due to the possibility of adding new CSS variables in scope.
kmruiz
force-pushed
the
fix/render-document-after-parent-changes-class-with-css-vars
branch
from
38138cf to
3437c81
Compare
|
@kalenikaliaksandr Done! If this message is not clear enough I believe I can tweak it a little bit more. |
|
@kalenikaliaksandr it seems that CI is failing with the new commit, could it be some flaky tests? The code didn't change, only the commit message. |
Yeah the CI failure at https://github.com/LadybirdBrowser/ladybird/actions/runs/13751716386/job/38599825023?pr=3853 isn’t unique to this branch |
This change forces an element to render again when it depends on custom CSS properties on any attribute change. Essentially, CSS custom properties could be attached on an element by using any selector, based on any attribute, so ideally if the current element is using CSS Custom Properties they need to flow down the tree.
It attempts to fix #3838 and there is a test that should validate the new behaviour.
Behaviour with the fix: