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.
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?
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)
(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
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.
You had me at deepfried.js (I'm not being helpful).
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 ).
...understood that long-polling in particular may be frustratingly difficult to differentiate from just a really slow server.
(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?
(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.
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.
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.