CSS url() doesn't respect cache refresh
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: ossman, Unassigned)
Details
Attachments
(1 file)
|
229 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0
Steps to reproduce:
- Set
background: url("foo.png");on an element - Load page
- Replace
foo.pngwith a different image - Reload page
Actual results:
Firefox shows the old contents of foo.png.
Expected results:
Firefox shows the updated contents of foo.png.
| Reporter | ||
Comment 1•10 months ago
|
||
Having Developer Tools open and Disable Cache enabled doesn't do anything about the issue. You also don't see any attempt to load/refresh the image in the list of network requests.
Opening the image URL manually shows the correct image. But it doesn't overwrite the cache, so the html page still shows the old contents even after a refresh.
The oddest behaviour is that you can inspect the element, disable and enable the background entry, and get the correct contents to show up. But again, the cached contents isn't fixed so a refresh of the page restores the old data from this magical cache.
| Reporter | ||
Comment 2•10 months ago
|
||
Partial test case. Simply but any image called "background.png" in the same directory and load the page. Then remove "background.png" and put in a different image with the same filename. Then try to get Firefox to actually show that image.
Comment 3•10 months ago
|
||
Did you try shift+reload?
| Reporter | ||
Comment 4•10 months ago
|
||
Also no effect.
I think I'm also seeing the bug on Firefox for Android, although I didn't investigate as deeply there.
Comment 5•10 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 6•10 months ago
|
||
Hmm.. Confirming. Of all things, Shift+R should at least cause a full reload.
Not sure what component makes the caching decision exactly, but for now, keeping it on CSS side.
Description
•