Open Bug 1851349 Opened 2 years ago Updated 1 year ago

Cached css served from a local web server without cache-control header not applying until manually force-reloaded

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Version:
Firefox 118
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: pqwoerituytrueiwoq, Unassigned)

Details

Attachments

(1 file)

Screenshot_20230902_211328.png
197.61 KB, image/png
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

Made a html file on my local server with a attached CSS style sheet (link tag stylesheet)
Opened the html page in the browser
Made a change to the CSS file on the server
Refreshed the page
Navigated to the css file and refreshed it so that the cache is updated
Went back to the html page and refreshed it to see the results

Actual results:

The changes are not applied, inspet element shows the new values in the css, but computed values are still the old ones

Expected results:

the computed values should match the css file in the cache, it should use the updated cache not the old cache

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Layout
Product: Firefox → Core
Component: Layout → CSS Parsing and Computation

Does ctrl+F5 help? How is the file served (which headers, etc)?

A way to reproduce locally would be great, otherwise this is not really actionable. Thanks!

Flags: needinfo?(pqwoerituytrueiwoq)

A hard refresh (Shift + F5) did work temporally, it reverted on another tab and F5 only did not help, at this time reproducing this event has worked it self out... i can try to make it happen again

at the moment the cache is updating every time the server's file changes using test.html/test.css and when i alter the original file that i was getting the issue with, Aright now i cant get it to even use the cached page after i alter the source css file

very annoying that [CTRL] + [refresh button] also open a new tab... (using F5 works)

response headers:

HTTP/1.1 200 OK
Date: Tue, 05 Sep 2023 14:24:06 GMT
Server: Apache/2.4.52 (Ubuntu)
X-Content-Type-Options: nosniff
Last-Modified: Sat, 02 Sep 2023 19:40:39 GMT
ETag: "c52-6046573b7fc8b-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
X-Frame-Options: SAMEORIGIN
Content-Length: 1006
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/css

request headers:
GET /music/outputs/style.css HTTP/1.1
Host: 10.0.0.69:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0
Accept: text/css,/;q=0.1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.0.0.69:8080/music/outputs.html
DNT: 1
Connection: keep-alive
Cookie: oclg58r5j0ay=c3t25o9tim0qndj9stdt1j3j3j; PHPSESSID=nejju4ahcf92uae13rc5t0njpq
Pragma: no-cache
Cache-Control: no-cache

normally if i am having a cache issue i will navigate to the file i want to update and F5 it verify i see the change then go back to the document and see the change applied, this time (not the 1st time it has been a issue) and when i look in inspect element i see the new values but have the old vales rendered

Flags: needinfo?(pqwoerituytrueiwoq)

(In reply to pqwoerituytrueiwoq from comment #3)

very annoying that [CTRL] + [refresh button] also open a new tab... (using F5 works)

I think the right thing to use with the button is shift. Don't ask me why tho :)

HTTP/1.1 200 OK
Date: Tue, 05 Sep 2023 14:24:06 GMT
Server: Apache/2.4.52 (Ubuntu)
X-Content-Type-Options: nosniff
Last-Modified: Sat, 02 Sep 2023 19:40:39 GMT
ETag: "c52-6046573b7fc8b-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
X-Frame-Options: SAMEORIGIN
Content-Length: 1006
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/css

Hmm... So the server isn't telling us anything about not caching this, so we keep this in the memory cache I believe.

request headers:
GET /music/outputs/style.css HTTP/1.1
[...]
Pragma: no-cache
Cache-Control: no-cache

I assume these are from the shift-reload, right? Presumably for regular loads we don't send these pragma headers.

Flags: needinfo?(emilio)

This is from pressing enter on the address bar
GET /music/outputs/style.css HTTP/1.1
Host: 10.0.0.69:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0
Accept: text/css,/;q=0.1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.0.0.69:8080/music/outputs.html
DNT: 1
Connection: keep-alive
Cookie: oclg58r5j0ay=c3t25o9tim0qndj9stdt1j3j3j; PHPSESSID=nejju4ahcf92uae13rc5t0njpq
If-Modified-Since: Tue, 05 Sep 2023 14:30:42 GMT
If-None-Match: "c52-6049d78be7cad-gzip"

Anyway i got it to happen again

  1. Change server source file
  2. reload page
  3. See that it is it is using a cached copy
  4. navigate the the updated source file/music/outputs/style.css
  5. press F5 if needed
  6. click back
  7. see old data
  8. press f5
  9. still old value
  10. inspect see new value with old value rendered

Request header for html file:

GET /music/outputs.html HTTP/1.1
Host: 10.0.0.69:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.0.0.69:8080/music/mpc.php
DNT: 1
Connection: keep-alive
Cookie: oclg58r5j0ay=c3t25o9tim0qndj9stdt1j3j3j; PHPSESSID=nejju4ahcf92uae13rc5t0njpq
Upgrade-Insecure-Requests: 1
If-Modified-Since: Tue, 25 Jul 2023 13:59:17 GMT
If-None-Match: "ce3-601502307f740-gzip"

Response header:
HTTP/1.1 200 OK
Date: Tue, 05 Sep 2023 14:53:05 GMT
Server: Apache/2.4.52 (Ubuntu)
X-Content-Type-Options: nosniff
Last-Modified: Tue, 25 Jul 2023 13:59:17 GMT
ETag: "ce3-601502307f740-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
X-Frame-Options: SAMEORIGIN
Content-Length: 746
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

Request header (for the css page in it's own tab)
GET /music/outputs/style.css HTTP/1.1
Host: 10.0.0.69:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Cookie: oclg58r5j0ay=c3t25o9tim0qndj9stdt1j3j3j; PHPSESSID=nejju4ahcf92uae13rc5t0njpq
Upgrade-Insecure-Requests: 1
If-Modified-Since: Tue, 05 Sep 2023 14:47:56 GMT
If-None-Match: "c52-6049db6604b47-gzip"

Response:

HTTP/1.1 200 OK
Date: Tue, 05 Sep 2023 14:54:57 GMT
Server: Apache/2.4.52 (Ubuntu)
X-Content-Type-Options: nosniff
Last-Modified: Tue, 05 Sep 2023 14:47:56 GMT
ETag: "c52-6049db6604b47-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
X-Frame-Options: SAMEORIGIN
Content-Length: 1007
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/css

When you do this the cache is updated but the rendered/computed data does not get updated

When you do this the cache is updated but the rendered/computed data does not get updated

Ok, so looking at this this is kind of expected. The in memory cache doesn't revalidate resources unless:

  • Expired.
  • Has a cache-control header with the no-cache or must-revalidate tokens.

Which this file is neither.

Just browsing to the css file doesn't quite invalidate the stylesheet cache.

You can force the reload by Ctrl+F5 which I think it's the simpler case.

Maybe we could add an heuristic to always revalidate if the URL is local, but it's my understanding that you're using http://10.0.0.69:8080 as the host, which doesn't give us any easy hint (like the hostname being localhost or what not). Plus it'd be just that, an heuristic...

Flags: needinfo?(emilio)
Summary: newly cached css not applying → Cached css served from a local web server without cache-control header not applying until manually force-reloaded

localhost = 10.0.0.50, server = 10.0.0.69

Just browsing to the css file doesn't quite invalidate the stylesheet cache.

In the event that doing so updates the cache it should (eg ctrl+f5 on the css file)

following this logic:

if (cache_date > stylesheet_cache_date) // note issue as of Tuesday, 19 January 2038 for 32bit systems
update_stylesheet_cache()

The network cache is separate from the in-memory stylesheet / image caches, so it's non-trivial.

Severity: -- → S3
Priority: -- → P3

it could flag the stylesheet cache as expired, i am guessing stylesheet cache is like a render cache, so updating from css source directly would be a pain

Reproduced in Firefox 120.0 and 120.0.1. Was very annoying as I'm trying to learn service workers, and seeing a new service worker appear to respondWith a stylesheet from an old one's cache made me think I was doing something wrong.

I stumbled upon something similar, however with a cache-control header and max-age directive.

The effect was that the style editor has picked up the refreshed styles and showed them in the developer panel (so the network cache was properly updated), but the web page has not changed. Adding a blank in the style editor will update the web page, as well as restarting Firefox or hitting CTRL+F5 as mentioned earlier.

Reproduced on

  • Ubuntu 22.04 Firefox 125.0
  • Windows 10 Firefox 125.0.1

I have opened a reproduction web page that is served on Express.js on GitHub: https://github.com/c-kunz/firefox-issue-1851349

Flags: needinfo?(emilio)

I'm confused at the repro in comment 12... The expectation that fetch() would somehow clear the in-memory cache is just not correct?

Flags: needinfo?(emilio)

IIRC I think I've run into image bugs where fetch was used to clear an image from the cache because it worked like that in Chrome.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #13)

I'm confused at the repro in comment 12... The expectation that fetch() would somehow clear the in-memory cache is just not correct?

Sorry, didn't mean to confuse anyone. If I may clarify: the style editor shows different styles than what the web page is actually displaying. That was causing confusion on my end.

I kind of expected that when network cache was refreshed, that the in-memory stylesheet cache was also refreshed, but judging by your reaction it seems like this is on purpose (for performance reasons?). Anyhow, I found a workaround to reload the website with location.reload(true) - that solves the issue I had on my end.

I see, that indeed can be confusing.

(for performance reasons?)

Kind of. The in-memory cache sits on top of the network cache, and it's resource-type-specific... So a random fetch() doesn't go through the stylesheet cache at all and thus has no impact on which entries it holds. Same with the image cache (what Tim mentions in comment 14)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: