1981164 - Response of cached stylesheet is empty

Status: NEW

(DevTools :: Netmonitor, defect, P3)

Description

[Nicolas Chevobbe [:nchevobbe]]

Steps to reproduce

1. Navigate to https://travel.glob.au/statistics
2. Open DevTools, select the Netmonitor, make sure to not have the disable cache checkbox checked
3. Reload the page
4. Find stats.css requests, select it
5. In the sidebar, select the Response tab if it wasn't selected already

Expected results

I'm able to see the stylesheet content

Actual results

The response panel says No response data available for this request

---

Note that for cached JS requests, the response panel do show the content fine

Comment 1

[Julian Descottes [:jdescottes]]

Investigate where this is coming from

Comment 2

[Julian Descottes [:jdescottes]]

The stylesheet cached responses are fully handled in content processes (same as images) and we don't have a generic way to retrieve the original text content for those cached responses.

We only recently started showing those cached requests (thanks to Bug 1916960). If we cannot get the actual content for the cached response, we should at least show a message in that panel instead of leaving it blank.

Arai, do you know if there is a way to get the content as text for cached stencils / resources. Worst case scenario we could try to get the actual stylesheet object matching the URL if it is effectively applied to the document, but it would be great to have something tied to the http-on-resource-cache-response observer notification.

Comment 3

[Tooru Fujisawa [:arai]]

For scripts, the script source can be available at least as C++ data as a part of JS::Stencil's, but it's not exposed to the observer notification.
The script source can be missing if the script source is discarded, but iiuc it's true only for chrome-privileged code, and web contents are not affected.
So, we can add the data to the observer notification or something for scripts.
The question would be how to associate the data, and when and how to perform the string conversion.
If the source string should always be provided as long as the observer exists, the we could do that synchronously at the same time as notifying.
Otherwise we might want to look into how to lazily perform it.

https://searchfox.org/mozilla-central/rev/202069c4c5113a1a9052d84fa4679d4c1b22113e/js/loader/LoadedScript.h#282,371

class LoadedScriptDelegate {
...
  JS::Stencil* GetStencil() const { return GetLoadedScript()->GetStencil(); }

https://searchfox.org/mozilla-central/rev/202069c4c5113a1a9052d84fa4679d4c1b22113e/js/loader/LoadedScript.h#57,249

class LoadedScript : public nsIMemoryReporter {
...
  JS::Stencil* GetStencil() const {

https://searchfox.org/mozilla-central/rev/202069c4c5113a1a9052d84fa4679d4c1b22113e/js/public/experimental/JSStencil.h#51

using Stencil = js::frontend::InitialStencilAndDelazifications;

https://searchfox.org/mozilla-central/rev/202069c4c5113a1a9052d84fa4679d4c1b22113e/js/src/frontend/CompilationStencil.h#1507,1512

struct InitialStencilAndDelazifications {
...
  RefPtr<const CompilationStencil> initial_;

https://searchfox.org/mozilla-central/rev/202069c4c5113a1a9052d84fa4679d4c1b22113e/js/src/frontend/CompilationStencil.h#1198,1251

struct CompilationStencil {
...
  RefPtr<ScriptSource> source;

https://searchfox.org/mozilla-central/rev/202069c4c5113a1a9052d84fa4679d4c1b22113e/js/src/vm/JSScript.h#385,513-514

class ScriptSource {
...
  // The set of currently allowed encoding modes.
  using SourceType =

For stylesheets, I cannot find any text source data available via mozilla::css::SheetLoadData, but I don't know much.
I'd like to forward the question to emilio.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

We don't keep the source string, no. See also bug 1769933.

Comment 5

[Julian Descottes [:jdescottes]]

Thanks for all the details Arai, one quick follow up question for cached JS files.

In my tests for "200 OK" cached JS files, I still capture a regular HTTP channel in the parent process and the response is copied via DevTools' NetworkResponseListener.

I thought that nowadays, JS files would be handled in the same way as CSS, and we would only be able to observe them via the observer notification. Maybe that only applies to es modules? Do you know where the different comes from?

Comment 6

[Tooru Fujisawa [:arai]]

This issue happens only with the in-memory cache, which is different than the necko's cache.
The in-memory cache for JS is not yet enabled by default, and the "cached" for JS files just means it's retrieved from the necko's cache, and iiuc if the necko's cache is used, the DevTools would just receive the response body in a normal way.

The similar issue would happen if you flip the dom.script_loader.navigation_cache pref.