Created attachment 364397 [details] demonstrates issue as well as source html Summary: It appears that Safari is recalculating CSS variables and updating unrelated DOM nodes any time the DOM is changed. I have created a tiny test page that includes a :hover rule on the body element and a CSS variable for a div which assigns a background image. Every time I trigger the body's :hover rule it seems to recalculate and update the div's background image (even though the resulting value is unchanged.) In the case where the image is not cacheable this causes the image to reload every single time the :hover rule activates/deactivates. Expected Results: CSS variable evaluation should not have any side effects if the calculated value is unchanged. Actual Results: In my example, uncached images are reloaded. This also happens on iPad (and presumably iPhone).
<rdar://problem/48950241>
Please attach the source in a non-video form.
Created attachment 365041 [details] Source file to demonstrate.
I am also running into this issue. I converted the issue author's example into a CodePen to make it a bit easier to access: https://codepen.io/liamdebeasi/pen/QRdjQp I can confirm this issue is happening on Safari 12 macOS, Mobile Safari on iOS 12.2, and WKWebView on iOS 12.2. This issue does not happen when the value of CSS variable is a base64 encoded image.
Hi folks, it doesn't appear this bug is getting any traction. This is causing us not to be able to implement important work around web components in an enterprise environment. Do you all have any feedback on when this will be addressed? Cheers
Simon: You'd asked for the OP to provide a repro in non-video form, which has now been provided. Can you please assign this for someone to investigate?
Also stuck with this problem. Would be awesome if someone could take a look. Does affect ionic hybrid apps a lot.
The issue doesn't repro with the linked codepen anymore (in trunk or STP) because :hover is better optimized and only invalidates the target element. The underlying issue (uncacheable resources referenced using variables are reloaded on style update) still remains, it can be seen by modifying the test to have :hover and backround on the same element.
To facilitate others looking at this, I've applied Antti's suggested refinement to Liam's repro to reproduce the issue in STP: https://codepen.io/JanMiksovsky/pen/PoZozRw Antti: Many, many thanks for taking a look at this. Since this issue has once again been confirmed, and continues to affect a range of organizations, could you help get this issue to assigned to someone?
Yes, I'm taking a look. Note that we don't really use the assignee field in bugzilla so it is not indicative of anything.
This is really about caching policies. The problem reproduces with <img> without any CSS, see https://codepen.io/anttikoivisto/pen/zYrYLwP
Antti, that repo is different in that it's creating new image elements and setting their src attr. I would expect an image fetch in that case when cache is disabled - that makes perfect sense. But in the css var example, the value of the background property on the test div is constant. So it appears that property is getting reevaluated and reset on the element, even though its value is unchanged. That doesn't sound right. This would be an issue for any element that rendered non-cacheable assets.
CSS variables are evaluated at style resolution time. Side effects like resource loads are retriggered. The behavior difference with other engines seen here is a result of different caching behavior (WebKit respects the uncacheable redirect of the referenced resource). I confirmed this with a Firefox engineer too. You see a variant of caching-dependent behavior on Chrome too if you open the codepen into two separate windows and hover between them.
We may need to change the caching behavior though if this is a web compat issue.
Note that the document-dependent caching behavior for <img>, at least, is specified in https://html.spec.whatwg.org/#the-list-of-available-images. See the "ignore higher level caching" flag. It would make sense to me to use the same policy for CSS-loaded images, fwiw.
Yeah, makes sense. I didn't know this is specced.
My team at Salesforce is creating a styling api using CSS custom properties. Due to this bug and another issue where declaring a large number of variables on :root causes a perf issue, we're forced to give Safari static values instead of the customizable experience Chrome and Firefox will receive. Is there any hope in getting Safari's performance in line with other browsers so we don't need to exclude it any longer?
Continuing work in bug 216048 *** This bug has been marked as a duplicate of bug 216048 ***