Polish Headers Side Panel

[janodvarko]

The Headers side panel (in the Network panel) would deserve some UI/X clean-up (this might be done as part of the Accordion refactoring see bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1613884

There are currently three expandable sections:

1. Response Headers
2. Request Headers
3. Request headers from upload stream

We could:

• Rename the third one to Request Payload
• Turn the general info at the top into an expandable section called General
• Move the Edit and Resend button to a new toolbar located at the top of the panel

WDYT? @digitarald @bomsy @fvsch

---

Open Questions

• Content for the summarized section
  • Single-line summaries for
    • Request: Method + Host + Path → Link to Request tab
    • Response: HTTP Code → Link to Request tab
    • HTTP/TLS Version → Link to Security
    • Size / Transferred Size + Time to Load → Link to Timing
    • Blocked Cookies? → Link to Cookies
    • Referrer Policy
• Information hierarchy:
  • Current:
    1. Summary, Headers (Request, Response)
    2. Cookies
    3. Params
    4. Response
    5. Stack Trace
    6. Security
  • Cleanup
    1. Summary + URL Params (Formatted/Raw) + Headers (Request/Response)
  • Combined headers section in summary vs headers inside Request/Response tabs 2. Request (Formatted/Raw) 3. Response (Formatted/Raw) 4. …
• WebSockets in Messages or Response?
• How could a consistent raw/pretty split/toggles for all data types (headers, params, payloads, cookies)
• Obvious copy/save for whole raw/pretty sections or specific entries and their parts (mostly name/value)
• How would a Copy/Save button work for the whole request/response?
• How would state for pending request, streamed request/response look like?
• Move Edit & Resend UI in the left sidebar to iterate on request data while observing responses
• Consistent filter in all important data types, to the top to be consistent with the other panels
  • How would the filter in the headers section be top-aligned
• Info panel header that highlights REST
• How to allow seamless selection of text sections

Decisions

• Rename the third one to Request Payload
• Toolbar located at the top of the panel
  • Edit and Resend button
  • More TBD

[digitarald]

There is both UI work to better align the space in this panel and UX for the information hierarchy.

From user feedback "network header tab is confusing", "a lot of information in a very compressed space – should be redone", "easy selecting and copy-pasting of request/response headers (for example: right-click header name and have the option to copy the name, value or name and value)."

Constraints that I'd like to throw in:

• Consistent raw/pretty split/toggles for all data types (headers, params, payloads, cookies)
• Consistent search in all important data types
• Obvious copy/save for whole raw/pretty sections or specific entries and their parts (mostly name/value)
• Maybe: States for pending request, streamed request/response

Questions:

• Would it make sense to move away from tabs to one accordion holding more/all sections?

[fvsch]

Would it make sense to move away from tabs to one accordion holding more/all sections?

Many sections have sub-sections, so we'd end up with like 10 accordion items which is a bit much. And for sections like Messages (websocket) it's useful to have the full sidebar's height available.

Consistent raw/pretty split/toggles for all data types (headers, params, payloads, cookies)

I notice that the Debugger when for a standard checkbox (in the Event Listener Breakpoints accordion header). We could use that, or make a smaller toggle control (the current one is rather big) and use it in Debugger too.

Personally for Headers I'd be happier with a single "Raw Headers" toggle (next to "Filter Headers") that affects all sections.

Maybe: States for pending request, streamed request/response

Yes please! It's hard to figure out that a request is pending just by looking at the table row, and you're left wondering if something is broken when the details are blank.

[digitarald]

And for sections like Messages (websocket) it's useful to have the full sidebar's height available.

Agreed, beyond WS, preview, formatted payloads and timings work better with more space. Security could link to the cert viewer or inline it.

To simplify the tabs, Cookies and Params could be rolled into the main panel. They often end up empty as well.

Related, Honza and I discussed why WS' Messages could not be shown in Response.

[digitarald]

A related UX bug, improving the summary view for cached resources: https://bugzilla.mozilla.org/show_bug.cgi?id=1338065

[bomsy]

Also to add to the list of suggestions from honza above

• Can we move the filter headers to the top to be consistent with the other panels?

[fvsch]

Can we move the filter headers to the top to be consistent with the other panels?

A small toolbar with "Filter Headers" and a toggle for "Raw Headers" would be great. It'd be consistent with the Messages tab, or with what we have in the Inspector for Computed styles, for instance:

One difficulty is that those controls wouldn't affect the first block of information with the URL, Status, HTTP version etc. That could make the top placement a bit awkward.

[janodvarko]

Great, I really like these ideas (search box within a toolbar at the top) Created a bug for it: https://bugzilla.mozilla.org/show_bug.cgi?id=1617167

Honza

[digitarald]

Great, I really these ideas (search box within a toolbar at the top)

I shared @fvsch's concern on how it doesn't search through the first part.

Maybe we can find a consistent toolbar that allows filter/copy/pretty-raw-toggle?

[digitarald]

I found Paw last week and found its UI for inspection nice and clean:

---

Splits data in Info, Request (Headers, Formatted, Raw) and Response (Headers, Formatted, Raw)

Prev/Next buttons in toolbar are nice affordance for navigating between ordered requests (often in REST and page load):

Summarized request/response meta data links to the Request/Response tabs:

Raw tab shows full HTTP (with basic highlighting for headers):

Share button to export & upload to online viewer:

[janodvarko]

I found Paw last week and found its UI for inspection nice and clean:

I can't open the Paw link (or is it suppose to be a link?)

[digitarald]

I can't open the Paw link (or is it suppose to be a link?)

Fixed. It is on paw.cloud :).

[digitarald]

Updating priority as @bomsy will be starting on this soon.

[digitarald]

@violasong fyi, we had some discussion today for some mock ups I made: https://www.figma.com/file/cf8pMDTvi64HWzRhQWdMnO/DevTools-Network-Details-Pane?node-id=32%3A2

[violasong]

I'm working on a mockup but here are some initial thoughts:

Could we hide the Cookies/Params/etc tabs if they're empty, or could this be confusing?

Paw is a great find! Nice example of Mac native patterns.

For copying, there are a couple things we could try:

• When selecting a row, Cmd/Ctrl-C should copy both name/value
• Double-clicking a name or value should select that whole string (currently the selection stops at any hypens, so for an example like this, it's hard to grab the whole name or value)
• Copy button that shows up on hover at the end of each row - maybe a bit much. Could be batched up with the info button which should be on the right side.
• Raw header sections could have an always visible copy button

Some little consistency issues that could be fixed:

• Accordion header text can currently be selected. Also, it has a blue background on hover.

States for pending request, streamed request/response

Curious about this, but need to learn more. What does this look like in other places?

[violasong]

Another thought I had - in the sidebar, Request URL, Method, and Status Code are a tad redundant with what would hopefully be showing in the table view. (Especially if we try something like hiding more of the other columns when the sidebar is open.)

[violasong]

I noticed Safari does this nice color coding. Does categorizing it this way make sense?

[violasong]

Ah, I looked at the Safari screenshot more closely and realized it just has more redundant info that's separated out. I like the visual styling though.

[digitarald]

Another thought I had - in the sidebar, Request URL, Method, and Status Code are a tad redundant with what would hopefully be showing in the table view. (Especially if we try something like hiding more of the other columns when the sidebar is open.)

I think I know what you mean. With the current table there is some redundance, but only "some" as the columns are often squished so small that the information can't really be seen. When we get around to minimize the table's sidebar-open mode to a single column this should not be an issue though, right?

States for pending request, streamed request/response

Pending requests will only have request parts (headers, payload, cookies, etc), but no response. Same for blocked requests btw. Streamed responses have some response parts and others are still coming in in chunks. There are also streamed requests, for multipart uploads; which have chunk request data in multiple parts.

[digitarald]

Ah, I looked at the Safari screenshot more closely and realized it just has more redundant info that's separated out. I like the visual styling though.

As usual, I don't understand Safari's color/icon choices ;) . But as long as things are readable and copy-able we are good. It feels similar to Paw's information hierarchy, which highlights key aspects in slightly bolder form and then just lists out the rest.

[violasong]

With the current table there is some redundance, but only "some" as the columns are often squished so small that the information can't really be seen. When we get around to minimize the table's sidebar-open mode to a single column this should not be an issue though, right?

True, especially if only show the filename. But I wonder if we might want to keep the status/method in the table.

Pending requests will only have request parts (headers, payload, cookies, etc), but no response. Same for blocked requests btw. Streamed responses have some response parts and others are still coming in in chunks. There are also streamed requests, for multipart uploads; which have chunk request data in multiple parts.

I see - so, assuming we can differentiate whether some data is either missing or waiting, we could indicate that.

[digitarald]

True, especially if only show the filename. But I wonder if we might want to keep the status/method in the table.

This reminds of of an idea I liked UX table, Row to Details. It compresses additional details into the remaining row.

I see - so, assuming we can differentiate whether some data is either missing or waiting, we could indicate that.

Yes, showing missing data as blank state (vs just not having the fields) makes sense.

Using phases from Resource Timing to map out which data gets available over time:

1. requestStart: Request headers available (for many failed/blocked requests, this is we ever have)
2. multipart/form-data requests (only important for file uploads): Chunked data are being added as they are sent
3. responseStart: Response headers available
4. responseStart to responseEnd: Response data chunks (and additional headers) available as they are received
5. responsEnd: All data available

@janodvarko did I miss a state?

[violasong]

Content for the summarized section

* Single-line summaries for
  * Request: Method + Host + Path → Link to _Request_ tab
  * Response: HTTP Code → Link to _Request_ tab
  * HTTP/TLS Version → Link to _Security_
  * Size / Transferred Size + Time to Load → Link to _Timing_
  * Blocked Cookies? → Link to _Cookies_
  * Referrer Policy

Some questions about this:

• What do you mean by "Link to Request tab"? (Different from the Request Headers section?)
• Should we also have a link to Cookies when it isn't a blocked request?
• Do we still want to show Address?

At first I was thinking of a menu-like UI like this

But the sections that these would link to don't seem obviously connected to me. It might be better to name them, e.g.

[janodvarko]

I see - so, assuming we can differentiate whether some data is either missing or waiting, we could indicate that.

Yes, showing missing data as blank state (vs just not having the fields) makes sense.

@janodvarko did I miss a state?

I think that we can see it a bit more precisely as follows: (but, the impact on the UI might be minimal)

• Request Start - Request headers available, POST data, request cookies, stack trace
• Sending POST Data - might take a time in case of big upload data
• Waiting for Response - might take a time if the server is slow. The server might be also in error state and no responsive (aka timeout)- in which case we might get no more data
• Response start - getting response headers, response cookies,
• Receiving data (aka downloading) Response data chunks (and additional headers) available as they are received
• Response end (or Request closed) - All data available now, no more data should be expected.

More info in HAR spec: http://janodvarko.cz/blog/har-12-spec/#timings

One more note. Request HTTP status is using a styled number in the first column

We can reuse the same style in the Headers panel.

Honza

[digitarald]

Related, I just checked out Safari's Network details pane which has some related ideas to grouping and labels (It is a bit hidden in Sources, which seems a nice touch, to have that information available in other panels; but kind of hard to discover):

• URL is broken down into its parts, making bits easier to copy/read and better represents concepts like REST. Maybe we could have an expandable section for that in the tree? Could we add IP there as well?
• Initiator line is called out
• Sizes are broken down into encoded, decoded (size in browser memory) and transferred. Compressed section is nice with the algorithm and the ratio – but why is not with the sizes, like 2.4kb (2.5x / gzip)?.

[digitarald]

@violasong looks great.

@bomsy looking at Victoria's work, it doesn't seem like we'd want to use the tree component for that. Or do you see that we should customize it to present data like that?

What do you mean by "Link to Request tab"? (Different from the Request Headers section?)

Sorry, the Params payload tab, which should be called Request for consistency.

Should we also have a link to Cookies when it isn't a blocked request?

Not sure where I would put this, so no.

Do we still want to show Address?

It would be important to know which server is resolved for some requests. See my analysis for Safari – maybe it fits with additional URL data.

But the sections that these would link to don't seem obviously connected to me. It might be better to name them, e.g.

I like the option as well. Maybe they could appear on hover to reduce UI density?

Regarding the labels, in the application panel design, we had more muted labels. Maybe we can try those out for comparison.

[violasong]

I like the option as well. Maybe they could appear on hover to reduce UI density?

That seems good, although maybe we want something there to encourage users to use the more contextual UI instead of looking through the tabs?

Regarding the labels, in the application panel design, we had more muted labels. Maybe we can try those out for comparison.

That subtler look could work if we keep the labels short to allow for more spacing, like this:

It wouldn't match the request/response headers though.

(Figma for all mockups so far)

• Blocked Cookies? → Link to Cookies

Should we also have a link to Cookies when it isn't a blocked request?

Not sure where I would put this, so no.

What should show up in the summary for Blocked Cookies?

[violasong]

Ideas:

Expand arrow on the URL opens to show query string params

Some syntax coloring on the URL (this doesn't look great, but maybe something similar could work

[violasong]

Idea:

More separation for warning/error messages in Header Summary

Or should we just put it at the top?

[violasong]

Idea: In header sections, show info (MDN link) and copy button on hover

[violasong]

Idea: All the above, with Response headers in blue sans-serif 12px labels + black monospace 11px values.