CSS fill color on SVG Path not rendered when parent CSS class change
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
People
(Reporter: info, Unassigned, NeedInfo)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: correctness, regression)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Firefox for Android
Steps to reproduce:
I set a fill color (for example fill: red;) as a css class and apply in a SVG <path> element, inline in my html file.
This SVG element is hidden by default with the attribute opacity: 0 and position: absolute outside the document/page, and will appear when Javascript change the class.
Actual results:
When Javascript changes that css class for a different one that has for example fill: green;, that SVG <path> didn't change to the green color. Unless I do hover or click on it (looks that any action to that element refresh the view and then show the green color)
Expected results:
When the css class change, the SVG <path> should apply that fill: color attribute.
I discovered this bug working on my website.
Here a temporary url to test:
http://nyiforu.cluster028.hosting.ovh.net
To reproduce the bug, scroll to more than half of the page and an Arrow2Top will appear at the right bottom side.
Then change the websime theme (by default light) to grey or dark (smalls squares inside the header of the page), and back again to scroll down... the arrow appears with the old color.
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 3•4 years ago
|
||
Please can you attach a minimal testcase to the bug. Preferably something 10-20 lines long rather than a complete website.
(In reply to Robert Longson [:longsonr] from comment #3)
Please can you attach a minimal testcase to the bug. Preferably something 10-20 lines long rather than a complete website.
I just copy/paste the code necessary to interact with the same behavior (sorry for the messy css/js)
https://codepen.io/ipuntoj/pen/BaLRZeo
Feel free to contact if any help needed!
Comment 5•4 years ago
|
||
I really don't know what I'm supposed to do or see here.
Scroll down, and you will see a circle with the scroll-progress and an arrow inside at the right bottom area.
Scroll up (back to the top) and change the theme color ( 3 mini squares at the right top )
Scroll down again, and you will see that the arrow keeps the old color even if the css class has a different fill: color;
Comment 7•4 years ago
|
||
I could repro that. This is the regression range mozregression came up with: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d09edbe2abfec5298b39ab5b30d45bf20b8bbe33&tochange=b3ecb5aef45a8fb74764bb32e54567d57ed00383
Comment 8•4 years ago
|
||
I bisected that manually since there were a couple suspect commits. It seems like a WebRender regression?
$ g bisect good
cd0999f15aef8e3d2a644a59ecbbed9896bcf108 is the first bad commit
commit cd0999f15aef8e3d2a644a59ecbbed9896bcf108
Author: Jeff Muizelaar <jmuizelaar@mozilla.com>
Date: Tue Sep 17 20:06:39 2019 +0000
Bug 1581953. Don't invalidate everything when the visible rect changes.
Differential Revision: https://phabricator.services.mozilla.com/D46218
gfx/layers/wr/WebRenderCommandBuilder.cpp | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
The issue does indeed not reproduce with WebRender disabled.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Description
•