Fixed
Status Update
No update yet.
Comments
ti...@ppi.de
Not sure if this is related to this issue: https://issues.chromium.org/issues/40137692
Update: In Safari it works as expected, so this really is only a Chromium issue.
Update: In Safari it works as expected, so this really is only a Chromium issue.
sa...@google.com
Thanks for the report and providing the repro case.
Reproducible on chrome stable #134.0.6998.45 with Mac 15.3, Linux debian and windows 11
repro on chrome channels
135.0.7049.3 canary/beta
135.0.7039.0 dev
Considering it as non regressin as the issue can be reproducible on older chrome versions #124.0.6338.0.
Reproducible on chrome stable #134.0.6998.45 with Mac 15.3, Linux debian and windows 11
repro on chrome channels
135.0.7049.3 canary/beta
135.0.7039.0 dev
Considering it as non regressin as the issue can be reproducible on older chrome versions #124.0.6338.0.
fs...@opera.com
I don't think the custom property/variable is required - just having the color-mix() with a currentcolor reference is enough.
ap...@google.com
Project: chromium/src
Branch: main
Author: Fredrik Söderquist <
Link:
Invalidate 'fill'/'stroke' color expressions on currentcolor changes
Expand for full commit details
Invalidate 'fill'/'stroke' color expressions on currentcolor changes
For the 'fill' and 'stroke' properties, changes to currentcolor wasn't
picked up if the <color> value was a function.
Add checks for said properties within the diff-field-flag block that
responds to changes in currentcolor. Rename the invalidation flag to
"color-parameter" instead of "background-current-color" since it's
applies to more properties than just 'background-{color,image}".
A test for this case already existed, but since it wasn't guaranteed to
have triggered paint before changing the style it would flakily pass
(most of the time). Add an additional rAF cycle to ensure paint has
occurred.
Fixed: 400828292
Change-Id: I2113162d58044df7027e48c7d59d3aa403142f17
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6333535
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/main@{#1429467}
Files:
- M
third_party/blink/renderer/core/css/css_properties.json5 - M
third_party/blink/renderer/core/style/computed_style.cc - M
third_party/blink/renderer/core/style/computed_style_extra_fields.json5 - M
third_party/blink/web_tests/external/wpt/svg/painting/color-mix-currentcolor-fill-stroke-repaint.html
Hash: bf7905fb34dc57b3c934c3b7bcb52ac2f7ea46ee
Date: Fri Mar 07 06:30:25 2025
ss...@google.com
Verified the fix on latest M136#136.0.7060.0 Using Linux debian and #136.0.7059.0 using Windows 11, Mac 15.3.1
Observed color change after hover over the boxes
Hence fix is working as expected, and the verified labels have been added.
Attaching screencast for reference.
Thank you..!
Observed color change after hover over the boxes
Hence fix is working as expected, and the verified labels have been added.
Attaching screencast for reference.
Thank you..!
Description
Steps to reproduce the problem
Problem Description
There is a CSS issue involving custom properties and the currentColor value in Chromium browsers that specifically affects SVG elements. If you update the color via the color property, the SVG element does not get repainted. The attached example does this on hover but the same issue occurs when you change the color property via a CSS class. If you force a rerender by some other case (I did it by resizing the window) the color updates.
I was only able to reproduce this with the combination of currentColor, color-mix and SVG. If I change any of those it works. In Edge this is broken as well, in Firefox it works. I was not able to test this in Safari.
Summary
CSS custom properties with currentColor and color-mix do not trigger repaint on change in SVGs
Custom Questions
Which component does this fall under?
Blink>CSS
Does this work in other browsers?
Yes - This is just a Chrome problem
Additional Data
Category: API
Chrome Channel: Not sure
Regression: N/A