Closed Bug 859138 Opened 12 years ago Closed 6 years ago

Add a plain text response view for json objects

Categories

(DevTools :: Netmonitor, defect, P2)

Product:
DevTools
Component:
Netmonitor
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: vporof, Unassigned)

References

Details

Attachments

(1 file)

Allow copying the network response string.
(deleted), patch
Details | Diff | Splinter Review
JSON responses are currently shown in a VariablesView instance. This is great, but if someone wants to batch-copy the exact response text, they're goona' have a bad time. Something like "view source" would be nice (this can even just simply open a new tab with the response listed as plain text). See also bug 859133.
Moving into Developer Tools: Netmonitor component. Filter on NETMONITORAMA.
Component: Developer Tools → Developer Tools: Netmonitor
Summary: [netmonitor] Add a plain text response view for json objects → Add a plain text response view for json objects
Priority: -- → P2
+1. I often run into this issue, and have to run another browser to copy the response text.
Here is a new version of the patch initialy submitted in bug 955933. It adds a test for the 'Copy Response as String' menu item.
Now that I'm thinking about it: a better solution could be to adopt the same behavior than for HTTP responses: having a "Preview" tab with a structured view of the content, and keep the "Response" tab plain-text. It would allow for other usages than just "Copy to clipboard" (for instance checking that the JSON is properly prettified or minified), and be more discoverable than a context menu. But it also would change the current behavior of the "Response" tab. Any thoughts on this?
(In reply to Pierre de La Morinerie from comment #6) > Now that I'm thinking about it: a better solution could be to adopt the same > behavior than for HTTP responses: having a "Preview" tab with a structured > view of the content, and keep the "Response" tab plain-text. > > It would allow for other usages than just "Copy to clipboard" (for instance > checking that the JSON is properly prettified or minified), and be more > discoverable than a context menu. But it also would change the current > behavior of the "Response" tab. > > Any thoughts on this? I like it. Also, this more-than-occasionally comes up in feedback: https://twitter.com/jessewilliamson/status/487591765697105921 Victor: what are your thoughts on this? The simplest workaround currently is to right-click on the request and open it in a new tab in Firefox.
Flags: needinfo?(vporof)
The way I see it, it's a bit tricky. If we were to be consistent, for example, we'd have images in the Preview tab, in which case we wouldn't display anything in the response tab? I would very much prefer a simple button on the JSON scope header (in the response tab) that opens a new tab with the plain text response. Same goes for request/response headers.
Flags: needinfo?(vporof)
(In reply to Victor Porof [:vporof][:vp] from comment #8) > The way I see it, it's a bit tricky. If we were to be consistent, for > example, we'd have images in the Preview tab, in which case we wouldn't > display anything in the response tab? I think it's worth considering the different classes of things and thinking about what a developer might want to do with the response: * js/html/css/ other text - need to copy the text or easily open in view-source / larger viewer * JSON - copy the text - view / filter / search the data structure * images - view the image, save it to disk? * non-image binary files - easily see the mime type, save it to disk? > I would very much prefer a simple button on the JSON scope header (in the > response tab) that opens a new tab with the plain text response. Same goes > for request/response headers. That make sense to me as well.
rtorruellas, this might give you something to work towards as you get to know the code? I can definitely help you on this also. ping me on IRC if you want to work on this!
Is this being worked on? It would be really helpful to be able to copy the JSON string without having to make another call in a new tab. Thanks
(In reply to Jan Lubeck from comment #13) > Is this being worked on? It would be really helpful to be able to copy the > JSON string without having to make another call in a new tab. Thanks FYI recently added a context menu item to copy the response of these requests, see bug 955933
Current suggested workaround, for the record, should be to open the json request in a new tab, which in dev edition which will provide the full JSON response view
It's a big problem when trying to diagnose errors in POST requests that are supposed to return JSON but aren't. I used to be able to get a raw text output to see what was being returned. All I get now is a blank response tab with 'SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data'
POST requests can not be easily opened in a new tab (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #15) > Current suggested workaround, for the record, should be to open the json > request in a new tab, which in dev edition which will provide the full JSON > response view (In reply to jade from comment #16) > It's a big problem when trying to diagnose errors in POST requests that are > supposed to return JSON but aren't. I used to be able to get a raw text > output to see what was being returned. All I get now is a blank response tab > with 'SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of > the JSON data' Just noticed 'Copy Repsonse' in the context menu that Jeff Driffiths mentioned. That is all I need, thanks. I should have read everything before posting.
The workaround 'Copy Repsonse' in the context menu is very useful. However, to really solve the problem 2 changes would be good: 1. fall back to the text parser if the default parser (JSON, image, ...) cannot parse the response, 2. a dropdown menu should enable to choose the parser: if the response has a wrong content type but the user wants to display the JSON view, it should be possible.
> Current suggested workaround, for the record, should be to open the json > request in a new tab, which in dev edition which will provide the full JSON > response view This doesn't work if response depends on some specific HTTP headers sent. Copying the response from context menu is not convenient when you need to look at raw response and copy some part of it. It would be more user friendly to have 'Raw data' button similar to the one at HTTP headers tab.
There are several more annoyances related to this: - a response body that looks like JSON is always treated as application/json, even if it is served as text/plain. (Reminds me of MIME Type Guessing in IE4…) - a response containing nothing but an empty array [] is displayed exactly like an emty object {} - Duplicate keys are not displayed (remember that {"a":1,"a":2} is perfectly valid JSON) This is because JSON.parse() does actually parses AND evaluates its argument, but who knows if I use a custom JSON parser that handles duplicate keys… - The tree is collapsed, and I could not find a way to expand all nodes by default, or with a single shortcut All these are not related to copying, but simply to viewing the response.
It's been 3 years since this harebrained "design" was introduced, and even after so many suggestions that it's counter-productive, the firefox team just doesn't have any desire to fix this simple problem. There was a time when atleast Firebug was better. But now? well, just look at this issue raised 18 months back: https://github.com/firebug/firebug.next/issues/326
I'd much prefer plain text first. If there's a JSON or ANYTHINGOTHER view then offer it as an alternative.
In Network tab, just right click the request then select Copy Response.
I wonder, this 5 years old request is still not addressed but its a simple usecase for developer to view response in raw format. For this, I need to run chrome in my machine. Earlier, firebug has this feature.
Seeing and copying raw response data should be possible when bug 1362036 lands (it's been pushed today) Honza
Product: Firefox → DevTools

:(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #26)

Seeing and copying raw response data should be possible when bug 1362036
lands
(it's been pushed today)

Honza

Should this be marked as fixed since bug # 1362036 was marked as verified? I just checked and it looks like its working fine.

Visual: https://i.imgur.com/lmP3Tes.png

Flags: needinfo?(odvarko)

Yes, this can be closed since this has been already implemented.

But the bug # you are pointing to is incorrect. Do you know the right bug? We should mark it as dup
(I can't find it atm)

Honza

Flags: needinfo?(odvarko) → needinfo?(lloanalas)

I didn't find any dup, but this is fixed, so I am closing it.

Honza

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #29)

I didn't find any dup, but this is fixed, so I am closing it.

Honza

I could not find it either. I just know I referred to that previous bug and when I tested it, it works fine on my end.

Flags: needinfo?(lloanalas)

Can we re-open this? Right now the FF dev tools only allows us to copy the whole JSON response. But we don't always want the whole response. Sometimes we only want one of the key, sometimes only one of the primitive values, sometimes a whole subtree.

It gets annoying when the JSON response is quite large, then we'd need to copy the whole response to a text editor and fish for the thing we're looking for, when we could already see the JSON pretty-formatted, right under our nose in the Response panel.

For the record, when viewing, for instance, HTML or CSS in the same Response panel, we can select and copy only the selection.

You should rather create a new request for your suggestion, because this one was explicitly for adding a plain text view for JSON objects.

Sebastian

Yep, I second Sebastian. Please create a new fresh report.
Honza

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: