Incorrect download of hidden background images
Reported by
sombragr...@gmail.com,
Sep 14 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Steps to reproduce the problem: 1. Have hidden elements with background image 2. Open the Dev Tools 3. Reload the page while observing the Network tab. Hidden elements will have their images downloaded nevertheless. What is the expected behavior? They should not be downloaded. What went wrong? Images are downloaded, hence wasting bandwidth. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 60.0.3112.113 Channel: stable OS Version: OS X 10.12.6 Flash Version: Shockwave Flash 27.0 r0 I'm pretty sure this worked before but I'm unsure on when this went awry. Tested this on Canary (63.0.3215.0) too and the issue is happening there too. I can confirm this doesn't happen on Firefox and Safari.
,
Sep 14 2017
,
Sep 19 2017
Adding Needs-Bisect, we'd like to see if this is actually a regression, and if so when it regressed.
,
Sep 20 2017
sombragriselros@ thanks for the issue. Tested this issue on Windows 7 and Mac OS 10.12.6 on the latest Stable 61.0.3163.91 and latest Canary 63.0.3219.0 using the below steps. 1. Launched Chrome and opened the attached .html on chrome. 2. Opened Devtools and navigated to Networks tab and reloaded the page. 3. Could observe that the files are getting downloaded. tested this issue on 50.0.2625.0 chrome version as well and could observe the same behavior. Please find the attached screen-shots for reference. Can you please provide us the screen-shot/cast of the expected behavior for better understanding of the issue. Thanks..
,
Sep 20 2017
Hello Susan, The cute_unicorn image shouldn't be downloaded at all. Background is hidden hence it shouldn't be downloaded. This behaviour can be seen on other browsers as you can see on the screenshots. I also think it makes sense to be able to save bandwidth. Seems counter intuitive to have to manually set a background image to none on mobile devices.
,
Sep 20 2017
Image doesn't get downloaded if parent is hidden and it's a background. Image elements seem to be always downloaded nevertheless, consistently with all browsers. This doesn't seem consistent to me and adding the need to wrap the element to hide it to avoid the download seems a bit tedious and counter intuitive IMHO.
,
Nov 24 2017
Thanks for the update! This is a Non-Regression issue since seeing this from M50 #50.0.2625.0, Making the status in Untriaged only so that the issue would get addressed. Could some one from Blink>Loader dev team please look in to this issue. Note : Able to reproduce the issue in Linux Ubuntu 14.04. Thank you.
,
Nov 30 2017
We, the loading module, don't know whether an image is hidden or not. The CSS module knows that, so adding Blink>CSS.
,
Nov 30 2017
ElementStyleResources::LoadPendingResources seems to load resources based on which ComputedStyles were constructed. I did some testing with background-image which shows: * We load background-image for the root element of a display:none subtree simply because we compute style to figure out that it's display:none. * We also load background-image for visibility:hidden and display:contents. * We do not load background-image for other elements in a display:none subtree. * We load background-image for an element in a display:none subtree if we query the style through getComputedStyle(). You can query any property to trigger the load, the essential thing is that the ComputedStyle is constructed. I haven't tested any other browsers or looked at any specs. Any changes in the policy here is probably done in ElementStyleResources based on the passed in ComputedStyle.
,
Nov 30 2017
Thanks for the investigation Rune. This doesn't sound like an interop/correctness issue as the page displays fine, but it may cause additional bandwidth use. It's been around for a while (see 5 year old question at https://stackoverflow.com/questions/12158540/does-displaynone-prevent-an-image-from-loading). I'll mark this as available, as it's a potential optimisation.
,
Dec 3
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 10
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by phistuck@chromium.org
, Sep 14 2017Labels: OS-Windows
Status: Untriaged (was: Unconfirmed)