web-platform-tests
Inconsistent results for test_page_with_cached_script_javascript between chrome and firefox
@OrKoN @sadym-chromium
We recently added new tests for cached network events for stylesheets, and the test at https://github.com/web-platform-tests/wpt/blob/db4fbbbda4c9327ba016cb34c28b910475b94e6f/webdriver/tests/bidi/network/response_completed/response_completed_cached.py#L453 seems to fail on Chrome.
Basically we load a page with 2 script tags pointing to the same (already cached) URL and Chrome in that case only emits a network event for 1 script request, while Firefox emits 2 events.
After checking internally on https://bugzilla.mozilla.org/show_bug.cgi?id=1922527 , it sounds like Firefox's behavior is correct, as each script should end up doing a main fetch. Can you check if this is correct and if there is potentially a bug on Chrome's side here?
I quickly tested it and it seems Chrome sends a single request if multiple script elements request the same script (cached or non-cached, only 1 request is shown in DevTools/reaches the server). There are some in-memory caches that are currently underspecified but it sounds like sending fewer requests might be better (in terms of page load time).
Thanks for checking! To be clear, when I am talking about performing a fetch, I don't necessarily mean that a request will be created. fetch can "fetch" directly from the cache without hitting the network. But the observable consequence will be that we will get dedicated network events in BiDi for the script tag.
For another similar test I wanted to add (for cached images), it's actually mentioned in the spec that implementations might bypass fetch and directly reuse the list of available images for the document, and that the way this list is built and made available is implementation specific. So for this particular test I will not add it to the shared wdspec tests.
But here for scripts it seems that the behavior with regards to fetch should be consistent across browsers? Unless as you said, this is due to the behavior of the in-memory caches, which is not clearly specified. And in this case, maybe caching tests for resources (JS, CSS, images) can't be written in a cross browser way. But that also means it will potentially lead to interop issues for folks writing tests involving such scenarios.
But here for scripts it seems that the behavior with regards to fetch should be consistent across browsers? Unless as you said, this is due to the behavior of the in-memory caches, which is not clearly specified. And in this case, maybe caching tests for resources (JS, CSS, images) can't be written in a cross browser way. But that also means it will potentially lead to interop issues for folks writing tests involving such scenarios.
yeah, I think this is what happens because DevTools also reports only a single network request. The second request is probably handled without issuing a new fetch and not reaching the CDP instrumentation point (which is before the fetch cache steps). Do I understand correctly that Firefox will issue two requests and both will be actually sent if caching is not configured by the server?
But here for scripts it seems that the behavior with regards to fetch should be consistent across browsers? Unless as you said, this is due to the behavior of the in-memory caches, which is not clearly specified. And in this case, maybe caching tests for resources (JS, CSS, images) can't be written in a cross browser way. But that also means it will potentially lead to interop issues for folks writing tests involving such scenarios.
yeah, I think this is what happens because DevTools also reports only a single network request. The second request is probably handled without issuing a new fetch and not reaching the CDP instrumentation point (which is before the fetch cache steps). Do I understand correctly that Firefox will issue two requests and both will be actually sent if caching is not configured by the server?
Ah good idea, I'll have to check without caching on the server side. I imagine Firefox will perform 2 requests in that case, based on what the spec says.