Closed Bug 1661478 Opened 4 years ago Closed 4 years ago

CSS/JS always cached, even after hardreload

Categories

(Core :: Privacy: Anti-Tracking, defect, P2)

Product:
Core
Component:
Privacy: Anti-Tracking
Version:
80 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: noah, Unassigned)

References

(Regression)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

MacBook Pro 15" 2016
2.9 GHz i7
16 GB 2133 MHz LPDDR3 RAM
MacOS Catalina 10.15.04
Fresh Firefox 80 installation, no settings modified, no plugins, clean profile

Writing new CSS / JS for a static website as well as in a PHP/Wordpress setup (no server-caching enabled).

Actual results:

The CSS / JS changes are not effective in Firefox after a reload, hardreload and complete cache/cookie deletion.

It takes several hardreloads and/or multiple complete cache/cookie deletion attempts before the changes take effect

Expected results:

Changes should take effect immediately after a hardreload.

Hi Noah,

Thanks for reporting this bug to us. I'll add it to the DOM: Core & HTML component so their team can take a look.

Can you please provide some examples so we can test it on our end? A screen recording will also be of great help.

Also it would be helpful if you can check if the issue occurs in Firefox Nightly as well. You can download it from here https://nightly.mozilla.org/.

Thanks!
Virginia

Component: Untriaged → DOM: Core & HTML
Flags: needinfo?(noah)
Product: Firefox → Core

Same for form fields, Ajax and some other elements ...
It's crazy to publish this in production ... It just push users to Chrome !

Can you elaborate / provide a way to reproduce this? Without any specifics it's hard to dig into it.

Alternatively, finding what change broke this using mozregression (https://mozilla.github.io/mozregression/install.html) would be equally useful.

This just started happening with v.80.

When developing a web page, this is how I can reproduce it:

  1. Load web page, e.g.: http://hidiho.localdomain/
  2. Make change to css source.
  3. Reload web page -- new css does not take effect.
  4. SHIFT-reload web page -- new css does not take effect.
  5. Open css file in new browser window. Changes are there.
  6. Do "Clear recent history", time range "Everything", cache is checked -- new css does not take effect
  7. Open Settings in developer tools. Click "Disable HTTP Cache (when toolbox is open)". Refresh page. -- new css does not take effect.
  8. Close tab. Do "Clear recent history." Open tab again -- new css SOMETIMES takes effect.

When #8 fails, nothing will do but to quit and re-launch Firefox.

It may or may not be interesting to note that I'm usually compiling css with "sass -s compressed --watch", and the result css has no line breaks.

How are you serving said website? The headers and such that it gets sent with likely matter.

Also, is it a regular <link rel="stylesheet">, @import, something else?

I've tried to reproduce with python -m http.server + a very simple html + css and couldn't reproduce it. If someone can give me steps to repro I'm happy to dig into this. If steps from 1 to 4 don't work something is clearly broken, regardless of headers.

P2 because it seems a regression confirmed by multiple people, but it seems not actionable right now :/

Severity: -- → S2
Priority: -- → P2

If you have a way to reproduce this but can't share publicly, please email it to me directly or what not, and I'll try to create a simpler repro :)

<link rel="stylesheet" href="/css/style.css">

I'm using apache httpd 2.4, from the Fedora 32 repo.

The file appears in the Network tab of Developer tools with a 200 status. It just seems like it's never re-parsed.

I'm also frequently "trying things" by editing css in the developer tools.

I can't guarantee that it doesn't have something to do with developer tool edits freezing the css in place. I'll have to play around a little bit.

Hmm, ok... I tried to serve something from my local httpd and the css response is something like:

HTTP/1.1 200 OK
Date: Thu, 03 Sep 2020 00:21:40 GMT
Server: Apache/2.4.46 (Fedora)
Last-Modified: Thu, 03 Sep 2020 00:20:38 GMT
ETag: "1c-5ae5db8c2ede4"
Accept-Ranges: bytes
Content-Length: 28
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/css

Which is fine and doesn't get cached as expected... I'm really curious into what is causing this, clearly a bunch of people is affected...

Here the problem is mostly on Prestashop 1.6 and Joomla 3.x websites.
This is one of headers :
[code]
accept-ranges: none
cache-control: max-age=2678400
content-encoding: gzip
content-length: 2020
content-type: text/html; charset=utf-8
date: Thu, 03 Sep 2020 08:57:16 GMT
expires: Sun, 04 Oct 2020 08:57:16 GMT
login: true
pragma: no-cache
referrer-policy: no-referrer-when-downgrade
server: nginx
strict-transport-security: max-age=31536000; includeSubDomains
vary: Accept-Encoding
x-cache-status: BYPASS
x-content-type-options: nosniff
x-firefox-spdy: h2
x-frame-options: SAMEORIGIN
x-powered-by: PleskLin
x-xss-protection: 1; mode=block
200 OK
[/code]

And Response header for a css file :
'HTTP/2 200 OK
server: nginx
date: Thu, 03 Sep 2020 09:06:07 GMT
content-type: text/css
last-modified: Mon, 13 May 2019 22:13:33 GMT
vary: Accept-Encoding
cache-control: max-age=10368000
expires: Fri, 01 Jan 2021 09:06:07 GMT
etag: W/"5cd9ec0d-72da3"
x-cache-status: BYPASS
x-powered-by: PleskLin
content-encoding: gzip
X-Firefox-Spdy: h2'

Ah! So, at least for comment 13, that response has conflicting caching instructions. It has pragma: no-cache, but also cache-control: max-age.

Our behavior there changed in Firefox 80 intentionally (bug 1649807), so that we now ignore the (non-standard) pragma header if the actually standard Cache-Control header is specified. We could consider reverting that if it causes lots of breakage, but I think the server should instead serve Cache-Control: no-cache instructions. Pragma was never supposed to work on HTTP responses.

The one in comment 14 seems like getting cached is the right thing to do, given that response. There's no Pragma: no-cache header there. It may be that the in-memory stylesheet cache isn't cleared properly. Hard-reload should definitely work to get the stylesheet reloaded though.

See Also: → 1649807

Comment 13 header is the one of a Prestashop login page.
Where i have to empty cache + CTRL F5 to have it work properly (it work fine under Chrome and Edge).
I understand what you mean ...
"cache-control: max-age=10368000" is a default directive added by general apache configuration for html elements.
But some specific pages (like backoffice) ad the "pragma: no-cache" because it's obviously needed.

I said a buulshit the "cache-control: max-age=10368000" seems to come from this NGINX directive :
# Expires map map $sent_http_content_type $expires { default 31d; text/css 120d; text/js 120d; application/javascript 120d; ~image/ 360d; } expires $expires;

OMG why i can't modify my comments ??

Sorry for the long silence, in the meantime I tried to create a HTML/CSS environment where the bug could be reproduced that I could share, without success.

So today I played around with mozregression, with this result:

Last nightly-build that worked: 2020.05.20
First nightly-build that did not work: 2020.05.21

These are the last few lines of the mozregression log:

2020-10-05T15:09:03.279000: INFO : Narrowed integration regression window from [2d00a1a6, 7e53b539] (3 builds) to [a55d8ca4, 7e53b539] (2 builds) (~1 steps left)
2020-10-05T15:09:03.318000: DEBUG : Starting merge handling...
2020-10-05T15:09:03.318000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=7e53b5398797485e8f326bde1fcb5820afcbc8a2&full=1
2020-10-05T15:09:03.319000: DEBUG : redo: attempt 1/3
2020-10-05T15:09:03.319000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=7e53b5398797485e8f326bde1fcb5820afcbc8a2&full=1',), kwargs: {}, attempt #1
2020-10-05T15:09:03.338000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2020-10-05T15:09:04.439000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=7e53b5398797485e8f326bde1fcb5820afcbc8a2&full=1 HTTP/1.1" 200 None
2020-10-05T15:09:04.544000: DEBUG : Found commit message:
Bug 1639154 - Isolate network cache per first-party when privacy.partition.network_state is set to true - part 2 - tests, r=mayhemer

Differential Revision: https://phabricator.services.mozilla.com/D75922

2020-10-05T15:09:04.545000: DEBUG : Did not find a branch, checking all integration branches
2020-10-05T15:09:04.547000: INFO : The bisection is done.
2020-10-05T15:09:04.548000: INFO : Stopped

Screenshot of the final screen of mozregression:
https://postimg.cc/HJL0bC7Z

Hope this helps, please let me know if you need additional info from me

Flags: needinfo?(noah)

Thank you! Not sure how actionable this is without being able to reproduce, maybe you can send credentials or something else to Andrea? Or maybe Andrea has any idea of where things could've gone wrong?

Component: DOM: Core & HTML → Privacy: Anti-Tracking
Flags: needinfo?(amarchesini)
Regressed by: 1639154
Has Regression Range: --- → yes

I had no issues for the last 3 days since I switched to the 2020.05.20 build. But today I used the Plugin called 'Firefox Multi-Account Containers', and inside these containers I have the issue again, but as soon as I use Firefox without a container-tab, everything is fine again.

Over the weekend I will try isolate the problem with a copy of a client website that has the problem. Hopefully I find something that makes it reproducible :)

I've made the update to v82 yesterday, no issues since then. Seams like the bug has been fixed :-)

Thanks Noah,

Per comment 21, I think we can close this bug for now. Feel free to reopen this bug if the issue is still present.

If you don't mind, could you help us to figure out which push fixes this issue. You can run the mozregression with --find-fix to do so. Really Appreiciate.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(amarchesini)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.