[Webkit-unassigned] [Bug 147022] Cached XHR requests are not shown in the web inspector

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 23 19:39:07 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=147022

Joseph Pecoraro <joepeck at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joepeck at webkit.org,
                   |                            |koivisto at iki.fi

--- Comment #4 from Joseph Pecoraro <joepeck at webkit.org> ---
In this test (as of today) Safari makes 2 requests. The first has a unique response, the second is shared by the remaining 9 XHRs. This behavior is equivalent to 10 <img src="..."> for the same URL. In that case, we also only see a single Resource in the Network Tab and Resources Tab.

In both cases, WebKit is making a network load, and while that load is in flight new requests are made for the same resource and we've determined that we can use the existing load's results.

Debugging with Antti we saw that we fall under this case in CachedResourceLoader::determineRevalidationPolicy:

>    if (existingResource->isLoading()) {
>        ...
>        // For cached subresources that are still loading we ignore the cache policy.
>        return Use;
>    }

The original article makes the point that:

> Looking at this, you can see Safari made one network request, which I
> suppose makes sense, but here is what ticks me off. Nowhere in this
> panel is any indication that it simply ignored my Ajax calls and used
> a cache result.

This is a fair point. We seem to be looking at two cases concerning the Memory Cache:

    1. A Request for a resource uses a response fully loaded response from our Memory Cache
      => Web Inspector shows this as a resource loaded from the Memory Cache

    2. A Request for a resource uses an ongoing request from our Memory Cache
      => Web Inspector is not informed about it

This is case (2). Possible solutions:

    Approach 1: Inform Web Inspector about Cache Hits for not yet loaded requests
      => We would see many XHR resources and Image resources for the above tests
      * We could show 10 network requests, with 1 a real load and 9 as memory cache.
      * We could do something like show the # of clients an individual response satisfied
        when it completed so we could show one load in the UI but also show that the load
        satisfied (10) clients. That begs the question of who the clients / initiators were.

    Approach 2: Do nothing, change XHR loading policy to match other browsers
      => Issue multiple XHR requests, which seems like what the developer expected anyways
      * Funnily enough this would match other browsers the most. Other browsers have the
        same behavior as Safari for the <img> case. They are just different in the XHR
        case because they send multiple requests.

    Approach 3: Special Cases
      => We could treat some subresource types as special to show ALL requests and others
      * This is essentially what other browsers have done at the engine level. Treating
        XHR loads different from Image loads, otherwise they would be seeing the same.

I don't yet have a strong opinion on whether we take approach 1 or 2. Either way it raises the point that if we want to show all of the initiators / requestors of a particular load, that if there are multiple initiators we might want to show them all.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170324/828116b0/attachment.html>


More information about the webkit-unassigned mailing list