SVG-as-background does not invalidate when using fragment ids
Reported by
witem.ar...@gmail.com,
Aug 13
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36 Example URL: https://codepen.io/witem/pen/QBoZgX Steps to reproduce the problem: 1. go to url 2. hover first icon, no effect 3. hover second icon, background-image changed What is the expected behavior? background-image changes in both cases What went wrong? I think Chromium not re-render element when in background-image changes only URL fragment(#) Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? Yes Chrome version: 68.0.3440.84 Channel: stable OS Version: Flash Version:
,
Aug 14
Able to reproduce the issue on chrome version on #60.0.3072.0, on reported version #68.0.3440.84 and on latest chrome #70.0.3521.0 using Windows 10, Ubuntu 17.10 and Mac OS 10.13.3, by following the steps in comment#0. This is a non-regression issue observed from old M-60 builds ,hence marking it as untriaged and requesting dev team to look into the issue. Thanks.!
,
Aug 14
Sending this to the SVG team to have a look at first.
,
Aug 14
This is an invalidation issue not related to fragment IDs, it seems. The background is only changing because the border color is changing. If the border color doesn't change on hover the background doesn't change, regardless of the fragment ID for the background.
,
Aug 14
it does not depend on the border color. In rule with hover need some css prop which will cause block re-render.
,
Aug 14
Sorry, the point is we are only invalidating when something other than the SVG is changing. I've updated the title.
,
Aug 14
I don't think it's paint invalidation - if we noticed the change in the fragment that'd probably work just fine. Dupe of issue 643716 . |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by swarnasree.mukkala@chromium.org
, Aug 13