Webpages render previously cached CSS changes
Categories
(Core :: CSS Parsing and Computation, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox-esr78 | --- | unaffected |
| firefox77 | --- | unaffected |
| firefox78 | --- | unaffected |
| firefox79 | --- | verified |
| firefox80 | --- | verified |
People
(Reporter: agibson, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
|
(deleted),
image/png
|
Details | |
|
(deleted),
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details |
image.png
Nightly 79.0a1 (2020-06-25) (64-bit)
macOS 10.15.5
When making changes to web pages on localhost, Nightly is rendering the previously cached version of CSS files, despite changes being loaded and reflected in DevTools.
The project I'm working on is https://github.com/mozilla/bedrock, but this is likely reproducable elsewhere.
STR:
- Load a webpage that references a CSS file in a Nightly tab.
- Make a small change to the CSS file, for example change the color of a background or some text.
- Refresh the browser tab.
Expected results:
Nightly should render the CSS change.
Actual results:
Nightly still renders the previously cached CSS, despite the browser (and DevTools) having loaded and parsed the changed properties.
Notice in the screenshot attached, DevTools correctly identifies the color of the heading as hotpink, but Nightly still renders the previous color (black). A second refresh fixes things and picks up the change.
I can't reproduce this issue in release or dev edition.
|
Assignee | |
Comment 1•4 years ago
|
||
So this is technically a regression from bug 1599160 (or follow-ups), unsurprisingly... But that means that your development server is sending us headers that allow us to cache stuff. It seems like devtools re-fetches everything again on their own, which is why you see it disagreeing with the page.
Can you give more information about your environment? What server are you using for development? Can you post an screenshot of the "Response" tab in the network panel for the stylesheet?
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 2•4 years ago
|
||
Ok, I can repro with a very simple python -m http.server and so on. I'll dig.
|
|
Assignee | |
Comment 3•4 years ago
|
||
Consider the case where we have an expired entry in the cache, and we
load a new document.
We get an speculative load from the HTML parser. That's great, and we
see the entry is expired and actually fired the load.
But then, we actually get to the load that the <link> element performs,
and we see that we've already performed this load, so instead of peeking
the in-progress load, we go ahead and peek the expired "complete" cache
entry, which is not what we want.
By marking a load as performed only once it has finished, we avoid the
complete sheet cache, and gloom onto the existing load instead, which is
the correct thing to do.
|
|
Assignee | |
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
|
||
Comment 4•4 years ago
|
||
Set release status flags based on info from the regressing bug 1599160
|
||
Comment 6•4 years ago
|
||
Backed out for perma failures.
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=307859601&repo=autoland&lineNumber=56369
Backout: https://hg.mozilla.org/integration/autoland/rev/54cec9fc8d4ea7e0964806d925961147dfa71410
|
|
Assignee | |
Updated•4 years ago
|
|
||
Comment 8•4 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 9•4 years ago
|
||
Comment on attachment 9159671 [details]
Bug 1648736 - Don't mark a load as performed on a given document until it has actually finished. r=#style
Beta/Release Uplift Approval Request
- User impact if declined: comment 0
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Create two files:
t.html
<!doctype html>
<link rel="stylesheet" href="t.css">
t.css
:root { background: red }
In that same directory run python -m http.server. Go to http://0.0.0.0:8000/t.html, and ensure you see a red page.
Change the contents of t.css to be :root { background: green }. Refresh the previous page.
You should see green instead of red.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Simple one-liner to avoid hitting the wrong cache.
- String changes made/needed: none
|
|
Assignee | |
Updated•4 years ago
|
|
|
||
Comment 10•4 years ago
|
||
Comment on attachment 9159671 [details]
Bug 1648736 - Don't mark a load as performed on a given document until it has actually finished. r=#style
Approved for 79.0b2.
|
|
||
Comment 11•4 years ago
|
||
| bugherder uplift | ||
|
||
Updated•4 years ago
|
|
||
Comment 12•4 years ago
|
||
I have managed to reproduce the issue using Nightly 79.0a1 (2020-06-25).
The issue is verified using Fx80.0a1 and Fx79.0b2 on Windows 10 and Ubuntu 18.04 based on the steps provided in comment 9. After the refresh, the color is correctly changed to green (updated color of the .css file).
|
||
Comment 13•4 years ago
|
||
I think this change is breaking sites. See bug 1673885.
Description
•