canmove, Confirmed users, Bureaucrats and Sysops emeriti
1,093
edits
DevTools/Features/NetworkView: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 37: | Line 37: | ||
Optional: | Optional: | ||
# | # request initiator | ||
# View JSON data as an object | # View JSON data as an object | ||
# View image thumbnails with the request for easy scanning | # View image thumbnails with the request for easy scanning | ||
# web sockets support | |||
# View customization | # View customization | ||
# View start time, completion time and duration for a request | # View start time, completion time and duration for a request | ||
| Line 48: | Line 49: | ||
# Make a new request | # Make a new request | ||
# HAR export | # HAR export | ||
|Feature functional spec==== Concise, Sortable View === | |Feature functional spec==== 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 | 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 | ||
| Line 108: | Line 117: | ||
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. | 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 [http://www.softwareishard.com/blog/har-12-spec/ 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. | |||
|Feature ux 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. | |Feature ux 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. | ||