[Feature]: Improve network tabs naming in Trace Viewer

[cpAdm]

🚀 Feature Request

When focusing on a network call in the trace viewer, show the following tabs:

• Headers (with collapsible sections: general (including start- & end-time), response headers, request headers)
• Payload (if given)
• Response
• Copy dropdown

Ideally also there should be more spacing between the property keys and values

Example

Current situation:

Newly suggested layout/names:

Motivation

The current tabs are confusing, and the copy buttons are hidden at the bottom of only the first tab. The new layout is clearer and aligns more with devtools in popular browsers.

I would be willing to implement (part of) these improvements.

[agg23]

It's unclear what you want to see. Could you possibly provide screenshots and a more thorough description with motivation for each change?

[cpAdm]

@agg23 I have updated the ticket with screenshots. So, its more about moving some components around to get it more aligned with browser devtools that we developers/testers are familiar with.

Additionally, each section inside a tab should be collapsible (and remembered) to let the user decide what he finds important. And by providing extra space between the keys and values it becomes way easier to read.

If you want to know more (details), let me know.

[agg23]

Understood. This seems like a reasonable request. We will consider a PR if you submit it.

[cpAdm]

@agg23 @pavelfeldman I would like to make the following changes, any open to a PR?

1. Make section headers collapsible

   

2. Remember collapsed state via localstorage

3. Show Headers count in 'Request Headers'/'Response Headers' header if section is collapsed
   

4. Add fixed spacing between key-values, values may wrap multiple lines

   

5. Re-arrange content to 'Headers (General, Request Headers, Response Headers) - Payload - Response' tabs

6. Add a 'raw' checkbox to see toggle between formatted and raw request/response headers

   

[agg23]

@cpAdm A few comments:

• Responding to an issue that is closed or tagged means that a number of the team won't see it/be notified by it. Some team members have disabled GitHub notifications or similar, and we have our own separate triaging process. Creating a new issue is a better way to get our attention/triage, even if it creates noise and may result in us simply closing certain things.
• We're going to start assigning issues like this to you with a release label; you can choose to address them or not, we just want to accurately track it. If you don't address the issues we'll eventually close them.

We want to be respectful of your time. We're cautious about reviewing PRs that have such "minor" (in scope) changes, but we recognize they are valuable and would like take those changes if the cost to us is very small. With that in mind, try to keep these PRs as small and easily reviewable as possible. Something we can glance at and approve is most likely to make it through; many lines of changed CSS are not because it takes significant effort to understand what is changing. You have done a decent job at this in the past, but I just wanted to inform you on how we're considering your changes.

[cpAdm]

Thanks for the response! I already had a feeling that not everyone has notifications turned on, which is understandable with a project of this size. Great that I can contribute. Makes total sense that any external PR's should be quick to review, with minimal (visual) changes. Will keep that in mind.