Bug 227631 - WebInspector: Network: Preview Tab errors out consistently when focused on XHR request
Summary: WebInspector: Network: Preview Tab errors out consistently when focused on XH...
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Razvan Caliman
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-07-02 11:18 PDT by Razvan Caliman
Modified: 2021-09-17 00:42 PDT (History)
5 users (show)

See Also:


Attachments
Screenshot of issue (488.80 KB, image/png)
2021-07-02 11:33 PDT, Razvan Caliman
no flags Details
WIP Patch 1.0 (2.50 KB, patch)
2021-07-02 11:34 PDT, Razvan Caliman
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Razvan Caliman 2021-07-02 11:18:16 PDT
<rdar://76783484>
Comment 1 Razvan Caliman 2021-07-02 11:31:09 PDT
Click a Fetch or XHR request while in-flight in the Network Tab (whiles still showing a loading spinner). 

The resource content view shows "An error occurred trying to load the resources" even after the resource successfully loads.

Steps to reproduce: 

- Got to https://music.apple.com
- Open WebInspector > Network
- Filter by XHR/Fetch (clear any resources already loaded)
- Click an album or playlist cover on the page to trigger some requests
- Immediately click a loading resource in the XHR/Fetch list
Comment 2 Razvan Caliman 2021-07-02 11:33:05 PDT
Created attachment 432806 [details]
Screenshot of issue

The error message does not got away once the resource has successfully loaded. This only happens if you catch an in-flight request.
Comment 3 Razvan Caliman 2021-07-02 11:34:32 PDT
Created attachment 432807 [details]
WIP Patch 1.0

Request for feedback on general direction
Comment 4 Razvan Caliman 2021-07-02 11:51:42 PDT
While an XHR/Fetch request is in-flight, its resource content view is  `WI.GenericResourceContentView.js`. 

It does not implement `contentAvailable()` so it throws an error and trips the catch in `WI.ResourceContentView` line 51:

```
resource.requestContent().then(this._contentAvailable.bind(this)).catch(this.showGenericErrorMessage.bind(this));
```

This causes the error to message to show up. 
The fix for this can follow the approach in `WI.TextResourceContentView`, implementing a no-op `contentAvailable()`.

---

Once the resource finishes loading, `WI.ResourceClusterContentView._resourceLoadingDidFinish()` tries to map an appropriate content view for the resource content type in `WI.ResourceClusterContentView._tryEnableCustomResponseContentViews()`. 

For JSON resources, this provides a `WI.LocalJSONContentView()`.

However, by this time, the `WI.GenericResourceContentView.js` is already rendered an associated to `this.responseContentView`.

To replace that view, we can manually call `this._showContentViewForIdentifier(ResourceClusterContentView.Identifier.ResponseJSON)`.


@Devin, Does this sound like a viable approach?

The `WI.ContentView.Event.SelectionPathComponentsDidChange` event is dispatched from `WI.ResourceClusterContentView._tryEnableCustomResponseContentViews()`. 

But that doesn't cause the automatic replacement of the generic resource content view. It looks like that was the intent at some point, but I don't follow. Perhaps I'm missing something?