Bug 227631 – WebInspector: Network: Preview Tab errors out consistently when focused on XHR request

• Component: Web Inspector
• Status: ASSIGNED

[Razvan Caliman]

<rdar://76783484>

[Razvan Caliman]

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

[Razvan Caliman]

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.

[Razvan Caliman]

Created attachment 432807 [details]
WIP Patch 1.0

Request for feedback on general direction

[Razvan Caliman]

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?