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

NEW
Unassigned

Status

()

Firefox
Developer Tools: Netmonitor
P3
enhancement
5 years ago
27 days ago

People

(Reporter: canuckistani, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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.
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
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).
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.
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.
Severity: normal → enhancement
You need to log in before you can comment on or make changes to this bug.