Open
Bug 1398276
Opened 7 years ago
Updated 2 years ago
"Disable cache" only to start
Categories
(DevTools :: Netmonitor, defect, P3)
Tracking
(firefox57 affected, firefox58 wontfix, firefox59 ?)
NEW
People
(Reporter: peterbe, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: parity-chrome)
Attachments
(1 file)
(deleted),
image/png
|
Details |
When you enabled "Disable cache" on the Network panel, it should disable any OLD cache but caching within the session. Like Chrome does it.
Steps to reproduce:
1) Open Network panel and click on "Disable cache"
2) Open https://www.peterbe.com/css-blocking/bootstrap-lazyloadcsswithjs-vanilla.html
Expected results:
That the first load of bootstrap.min.css should be a 200 with an actual network fetch, but that the second request should be using caching.
Actual results:
There are two distinct 200 OK requests for bootstrap.min.css (same for that other jumbotron.css)
Also, I can confirm that the network traffic is real because I get these four lines in my server log when I refresh the page:
73.180.105.76 - - [08/Sep/2017:18:55:02 +0000] "GET /css-blocking/bootstrap.min.css HTTP/1.1" 200 18617 "https://www.peterbe.com/css-blocking/bootstrap-lazyloadcsswithjs-vanilla.html" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0"
73.180.105.76 - - [08/Sep/2017:18:55:02 +0000] "GET /css-blocking/bootstrap.min.css HTTP/1.1" 200 18617 "https://www.peterbe.com/css-blocking/bootstrap-lazyloadcsswithjs-vanilla.html" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0"
Reporter | ||
Comment 1•7 years ago
|
||
The reason there are two requests at all for the same URL is to do with preloading followed by a piece of JS that changes the DOM and thus cause the browser to download it again. Yeah, that's nuts and a story for another bug but the point here is that the "Disable cache" should only be applicable for the stuff *before* the page is loaded.
Updated•7 years ago
|
Component: Developer Tools → Developer Tools: Netmonitor
This might be good improvement, but I wonder how often this issue comes up for real pages...? Hopefully it's not that common to request the same static files many times over on a real site...? Perhaps <iframe>s change the story a little, I'm not sure.
Updated•7 years ago
|
status-firefox58:
--- → fix-optional
Priority: -- → P3
Comment 3•7 years ago
|
||
status-firefox59:
--- → ?
Updated•6 years ago
|
Product: Firefox → DevTools
Reporter | ||
Comment 4•6 years ago
|
||
(In reply to J. Ryan Stinnett [:jryans] from comment #2)
> This might be good improvement, but I wonder how often this issue comes up
> for real pages...? Hopefully it's not that common to request the same
> static files many times over on a real site...? Perhaps <iframe>s change
> the story a little, I'm not sure.
I don't think it's unrealistic at all. Preloading (see comment #1) is a good example of this. Either by things like `<link rel="preload">` or by doing things like `var img = new Image(); img.src=IMAGE_URL;`.
Comment 5•6 years ago
|
||
Making this a parity bug as this becomes more impactful with the increase of caching options like preload.
Keywords: parity-chrome
Updated•5 years ago
|
Blocks: netmonitor-cache
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•