Personal tools

DevTools/Features/NetworkView

From MozillaWiki

Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Status

Network View
Stage Landed
Status Complete
Release target Firefox 23
Health OK
Status note Landed in Firefox 23

Team

Product manager Kevin Dangoor
Directly Responsible Individual Dave Camp
Lead engineer `
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members `

Open issues/risks

`

Stage 1: Definition

1. Feature overview

For web developers, the "Network Panel" serves two primary purposes: digging into the details of specific requests and viewing load time performance. For this feature, the focus is on finding the desired request and digging in to the details. Depending on schedule and the intersection with other features, we may also include the load time performance aspect as well.

2. Users & use cases

Troubleshooting client/server communication

Web applications often involve a lot of client/server communication. It is increasingly common for a web server to send the initial HTML page and then all further communication is in the form of JSON responses. In order to make sure everything is working properly, the developer needs to be able to look at the request and response headers, cookies, and the request and response bodies.

Fixing requests that were made incorrectly

A web app could get the URL wrong (causing a 404 response from the server) or make an HTTP request on a page that is HTTPS (causing potential security issues for the user). The developer will want to be able to spot these problems quickly and fix them.

Finding resources that need optimization

One developer wanted to identify large images that could be optimized better. Other developers want to be able to spot JavaScript files that are too large or not gzipped. During development, the resources might not be in their final form (compressed/minified JS and CSS, for example) which is okay at that time. Most developers want their production servers to be as responsive as possible.

Tracking slow page loads

Page load time is very important for the user experience of a website. There a few ways to help users improve their page load times. You could provide a list of events that occur during loading or specific recommendations about ways to improve performance. However, a graphical timeline is a quick way for a user to visualize load time bottlenecks and slow loading resources.

3. Dependencies

`

4. Requirements

  1. Concise, sortable view
  2. View should be easily scannable
  3. Be able to view the details of a request
  4. search for requests (search or filter would be nice)
  5. Filter requests based on type
  6. highlight errors (4xx, 5xx statuses)
  7. highlight HTTP requests for HTTPS page
  8. Display load time statistics
  9. remote capable

Optional:

  1. request initiator
  2. View JSON data as an object
  3. View image thumbnails with the request for easy scanning
  4. web sockets support
  5. View customization
  6. View start time, completion time and duration for a request
  7. request timing details (how long did each phase of the request take?)
  8. support for console.timestamp
  9. Syntax highlighting for HTML/JS/CSS response bodies
  10. Resend a request
  11. Make a new request
  12. HAR export

Non-goals

`

Stage 2: Design

5. Functional specification

Activation

As long as the network view is open (and ideally when any developer tools are in use), network traffic is logged including request and response bodies. It's important that the information is available to the user when they want it, without a reload. If none of the tools are in use, then it is acceptable for performance reasons to not track the requests (or the bodies of the requests).

Reload Behavior

By default, reloading the page or navigating to another page will clear the network view. This would be acceptable behavior for the first iteration of the tool. The other tools also allow keeping the existing network state while navigating as an option.

Concise, Sortable View

Users need to be able to quickly find the request(s) they're looking for and to spot unexpected problems. The view should include the following fields

  • URL
  • HTTP method (GET, POST, etc)
  • domain
  • response code
  • response size
  • mime type
  • remote IP address

Easy Scanning

To help users visually scan and identify the requests of interest, the display should highlight the most significant part of the URL, which would generally be the filename. Ideally, the display would adjust based on the unique parts of the URL. One possible approach:

  1. if the filename is unique among the URLs, just display that
  2. add as little of the path to the filename to create a unique value
  3. if the path and filename are not unique, look for query strings that differentiate the entries

Request Details

The request details should include basically the same information that is in the Web Console network panel. When the network panel is open the user should not have to explicitly turn on request/response body logging. Response body logging is expected when the user is viewing the network panel.

Request details should include a view of the cookies sent and set.

Search

The user should be able to search on the URL field. Searches should be case insensitive. Options could include regex matching and doing a filter rather than a search.

Request Filtering

Requests should be filterable on some common groupings:

  • image
  • stylesheet
  • script
  • xhr
  • fonts
  • websockets
  • documents
  • error/success
  • JSON?

The list of filters provided could be tailored based on the responses present. So, if no web fonts or websockets are used, those filters need not be displayed.

Highlighting Errors

It should be easy to spot requests with problems. Specifically,

  • 4xx and 5xx status codes
  • HTTP requests made from an HTTPS page

Load Time Statistics

Include a simple textual display of load statistics. Number of requests, amount transferred, time to onload/DOMContentLoaded.

Remote Capable

Loading characteristics can be quite different on a mobile device, so this feature should be designed to allow eventual remote capability. Remoting is not required at this stage.

Copy/Paste

Copying events to the clipboard doesn't appear to produce very good results in the current popular developer tools. If there was a mechanism to select some network events and copy them, it would probably be most useful to just copy them in HAR format. This is optional behavior.

Web Sockets

Web Sockets should appear among the network requests and should be easily visible as web sockets. For the first round, there is no need to provide visibility into the data traversing the web socket.

SPDY

Requests made with SPDY should be flagged as such, ideally in both the table view and the details. This would help developers ensure that requests they expect to be made with SPDY are made with SPDY. This feature is optional for the first round, but would be nice to have if it's easy.

6. User experience design

shorlander and kdangoor spoke about the UX a bit. We both have a preference for a table in which the leftmost column has the URL and the view of the other columns is replaced by the details (more like Chrome/Opera and less like Firebug's current implementation). That style allows users to quickly step through request details. Firebug's current implementation which uses a disclosure triangle and expands the details below is acceptable, though.

Honza is open to certain changes in the net panel in Firebug as well.

  • move method to a separate column (currently Firebug has it built into the URL field in the table)
  • replace most of the table area rather than expanding requests in place
  • thumbnail image on the left

Stage 3: Planning

7. Implementation plan

Work is ongoing here: https://github.com/firebug/httpmonitor

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

`


Feature details

Priority P1
Rank 3
Theme / Goal `
Roadmap Developer Tools
Secondary roadmap `
Feature list Desktop
Project `
Engineering team DevTools

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-needed assigned to mgoodwin
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `