876879 - New Netmonitor filters do not include $.getJSON / jsonp calls as 'XHR'

Status: NEW

(DevTools :: Netmonitor, enhancement, P3)

Description

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Test:

1. open the netmonitor, check the filter is set to 'All'
2. load this site: http://canuckistani.github.io/st-beer/
3. observe the XHR call made to live-menu.staugustinesvancouver.com/taps.json?callback=? is visible, but the text in the 'type' column is 'json'.
4. click on the 'XHR' filter, observe that all requests dissappear including the jsonp request.

Comment 1

[Victor Porof [:vporof][:vp]]

Hmm, they're not *technically* XHR requests, although, ignoring pragmatism, it'd make sense to add some smarts to the XHR filter to display them as well. Any thoughts on this? Rob? Mihai?

Comment 2

[Mihai Sucan [:msucan]]

How is that jsonp loaded? If it is not loaded using an XHR, then I would not stretch the concept to include json's loaded in other ways. It could cause confusion in the future.

(I don't have strong feelings about this - if others feel this is important)

Comment 3

[Victor Porof [:vporof][:vp]]

(In reply to Mihai Sucan [:msucan] from comment #2)

It's a hack. A terrible, terrible useful hack: http://en.wikipedia.org/wiki/JSONP#How_it_works

Comment 4

[Jeff Griffiths (:canuckistani) (:⚡︎)]

From a user's point of view, it is also often hidden away in abstraction by a framework. A library ( let's call it deepfried.js ) may use CORS requests when it can, xhr if we're on the same origin, or jsonp as a fallback if that's supported. The developers of deepfried have provided an abstraction in their api, and the specific technique used can vary between browsers depending on capabilities.

This is exactly how socket.io works - Firefox gets a websocket but IE uses Flash or long-polling as a fallback.

As a developer using deepfried.js, what I want to see is how my client-side, single page app is communicating with the server(s) & other services. I am going to be very interested in what technique the browser is using to do this ( this will have scaling impications ) but I also would love to be able to filter these types of 'data' connections from other requests.

Comment 5

[Victor Porof [:vporof][:vp]]

You had me at deepfried.js (I'm not being helpful).

Comment 6

[Mihai Sucan [:msucan]]

Jeff, thanks for your explanation. That makes sense. We could have jsonp show when you filter by XHR in the network monitor, but when the user clicks jsonp requests I would like us to make it clear to the user the difference between an actual XHR versus a <script> that loaded the jsonp. I don't know how we can best do this, but we should avoid causing confusion. Could we show the source of the request? For a jsonp we could show the <script> tag, for XHR we could show the JavaScript source code which triggered the load.

Comment 7

[Jeff Griffiths (:canuckistani) (:⚡︎)]

The network monitor's type column correctly identifies the request as JSON, but we have no filter that shows this JSON type request ( I can only see it by clicking on 'ALL' ) - I think this 'type' is a good enough indication for netmonitor.

To me 'xhr' is an implementation detail, as a developer I want to be able to filter for the types of remote data requests my app makes, and my app may make a mix of websocket, server-sent events, WebRTC, long-polling, xhr, same-origin json and jsonp requests depending on what back-end services it is using. I'm probably missing some, and I assume the web will invent new data channels as well ( or already has ).

Comment 8

[Jeff Griffiths (:canuckistani) (:⚡︎)]

...understood that long-polling in particular may be frustratingly difficult to differentiate from just a really slow server.

Comment 9

[Victor Porof [:vporof][:vp]]

(In reply to Jeff Griffiths (:canuckistani) from comment #7)
> The network monitor's type column correctly identifies the request as JSON,
> but we have no filter that shows this JSON type request ( I can only see it
> by clicking on 'ALL' ) - I think this 'type' is a good enough indication for
> netmonitor.

Maybe we should just have a JSON filter, near XHR?

Comment 10

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Victor Porof [:vp] from comment #9)

> Maybe we should just have a JSON filter, near XHR?

As long as you're comfortable with that many filters. We'll eventually add more ( websockets comes to mind ). 

I still think the more usable option is grouping things that perform essentially the same general type of request so that the developer doesn't need to worry so much about implementation details.

Comment 11

[Mihai Sucan [:msucan]]

Jeff has a good point about websockets and other things we'll want grouped under the same concept. Maybe we could rename the XHR to something more generic? If we don't have any better ideas, we can just go ahead and things we want under the same filter.

Comment 12

[Jeff Griffiths (:canuckistani) (:⚡︎)]

I think the best way to think of it is categories of types, for example in this case we could have types like websocket, xhr ( implies use of xml to me ), json, jsonp, server-sent-events, long-polling (?), etc could be grouped generically into a category I think of as 'API calls' or 'Data requests' or something. Please bike-shed the actual name, those ones suck.