Open
Bug 1338065
Opened 8 years ago
Updated 2 years ago
cached and 200 OK - Improving the visual layout of resources fetched from the browser cache
Categories
(DevTools :: Netmonitor, defect, P3)
Tracking
(Not tracked)
NEW
People
(Reporter: karlcow, Unassigned)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
(deleted),
image/jpeg
|
Details |
It's a couple of time I'm getting bitten by this UX/design issue in netmonitor. Context: Let's say you have a Web site sending a response with Cache-Control and Etag headers. For example: Cache-Control: private, max-age=3600 Etag: "foobar" The server tells us: 1. This resource has a lifetime of 1 hour for the Cache 2. During this 1 hour, use the resource in the cache 3. After this one hour, subsequent request will be sent with a 'If-None-Match: "foobar"' to check if the resource has changed. The first request gives a 200 OK and the browser generates a caching key for future validation. Then the next request, the browser doesn't hit the network and just uses the cached resource. My Issue: In the network panel, the line is showed as * a gray circle * 200 (when we over we get a "200 OK (cached)") * usual information * Transfer says cached when the resource line is clicked, we get the panel with headers fully displayed AND (0 B) beside the request and response headers. Response gives the response payload. I wonder if there would be a better way to convey the information that there was no interaction with the network at all. Probably the 200 is the thing which misleads me each time, because it is somehow means answer from a server. Thinking out loud. I don't have a solution, but things to test * Dropping the 200. * Changing the background-color to another light color * Cache Expiration time left, aka when will be the next request. 1st request: 1h then the next request, 45 minutes later, says: 15m. aka Expiring in 900s.
![]() |
Reporter | |
Updated•8 years ago
|
Summary: cached and 200 OK → cached and 200 OK - Improving the visual layout of resources fetched from the browser cache
Comment 1•7 years ago
|
||
All cache request rows will turn into grey color (new feature recently land in Nightly). Karl Dubost, do you think that grey color hint make this better?
Flags: needinfo?(kdubost)
Priority: -- → P3
![]() |
Reporter | |
Comment 2•7 years ago
|
||
yes Bug 1338386 solved a couple of issues, but not all. That's cool. Basically what I'm saying here is: Be explicit. The request/response panel doesn't have to use these keywords but something which helps devs to understand what is really happening. I would also remove the display of request headers, because they are not deserving any useful purpose here. This is different from a conditional request where there is a request happening resulting in 304. See the lose screenshot/mockup (better things can be proposed)
Assignee: nobody → kdubost
Flags: needinfo?(kdubost)
Updated•6 years ago
|
Product: Firefox → DevTools
Updated•6 years ago
|
Blocks: devtools-webcompat-team
Updated•5 years ago
|
Blocks: netmonitor-cache
Comment hidden (off-topic) |
Comment 4•2 years ago
|
||
Sorry, there was a problem with the detection of inactive users. I'm reverting the change.
Assignee: nobody → karl+moz
Updated•2 years ago
|
Severity: normal → S3
![]() |
Reporter | |
Updated•2 years ago
|
Assignee: karl+moz → nobody
You need to log in
before you can comment on or make changes to this bug.
Description
•