User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

I have send a POST request to an API. It has happened in Firefox 87 too.

Actual results:

My web application was unable to read the response but when I have looked at the API result in the Developer Tools > XHR > Response it looked like it had all the JSON fields and it looked well formatted, and with "Content-Type: application/json". It looked like the JSON data had no issues but 3 hours later when I have looked at raw data I saw that the response is an invalid JSON

Expected results:

The Developer Tools > Network > XHR > Response must not try to beautify the data if the string is an invalid JSON.

Note that the response headers have no issues. Content-Type: application/json

This bug probably was introduced in the last one year because in previous years Developer Tools > Network > XHR > Response was showing that the JSON was invalid while JSON data was invalid.

The Bugbug bot thinks this bug should belong to the 'DevTools::General' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Thank you for the report I can reproduce on my machine (Win 10, Fx Nightly)

STRs:

Fission need to be disabled, otherwise the document request isn't visible see bug 1705380

1. Load the attached page https://bug1708356.bmoattachments.org/attachment.cgi?id=9219133
2. Open DevTools and select the Network panel
3. Reload the page to see the page request in the list
4. Select the request and check out the Response panel
5. The response JSON is parsed just fine -> BUG (the JSON is invalid)

dfgddfgdfgfd{"body":{"foo":"bar"}}

The thing is that we are auto stripping the dfgddfgdfgfd part
This is a regression

Honza

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c6d9f195518ae979e430c411e1db2f45e448df98&tochange=4cee9ec9155ebe26d5004433fc78d3780b756c4b

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Hi, I would like to work on this issue If no one else is planning to take it.

Mattias

Sure Mattias. Go ahead .. Assigned.

It seems like this behavior was introduced intentionally in Bug 1635835 so that when people use XSSI prevention sequences prepended to valid JSON the JSON is still pretty printed. Maybe a good solution would be to display the prepended sequence in addition to the pretty-printed JSON or to only strip common XSSI prevention sequences like )]}, while(1), and for(;;). I think that displaying the sequence that was stripped is the best solution because it preserves the ability to pretty-print JSON with XSSI prevention sequences but also lets developers know that their JSON may not be valid in the case that the prepended characters are not for XSSI prevention.

Mattias

Here is what I was thinking for the info message. I'm not sure exactly about the wording but I think something like this strikes a good balance between telling people they might have invalid JSON and still allowing XSSI prevention sequences.

Mattias

Thank for the update Mattias!

The screenshot/mockup looks great. A few comments.

• Yes, this behavior was introduced intentionally in Bug 1635835 and we should first try to fix the parsing and handle only true XSSI prevention character cases. Bomsy, can you please help to identify which one are those and improve the parsing-logic behind?

• Let's experiment with the background color of the message and use the same light-blue as for the message used for multi line editor (see the attached screenshot)

• Also, we should default to the Raw data when XSSI characters are identified.

Hi Mattias,
WIP Patch is looking good

Depends on D115442

I was wondering, should we strip the XSSI protection characters when pretty-printing in the RequestPanel? From what I have read it seems like they will only be intentionally be included in JSON sent from the server but not in JSON that the client sends to the server. This makes it seems like there is no use for stripping them when pretty-printing in the RequestPanel but stripping them might cause someone to miss an error with their JSON in the rare case that they accidentally prepend one of the valid XSSI protection sequences to their JSON.

Good point, I agree.

You can file a follow up bug for this and fix it separately to keep the current patch simple.

Honza

Honza: some patches are waiting for review here, are they blocked on something?

Sorry for the delay on this!

@delosrogers: are you still interested in finishing the patches? It feels to be close to landing, Bomsy, just required some minor changes in the attached patches.

Yes I still am interested in finishing these patches, I just got really busy but I should be able to get the done this week/weekend.

Great, thank you for the update.
Honza

https://hg.mozilla.org/mozilla-central/rev/4ebfd72edcf3
https://hg.mozilla.org/mozilla-central/rev/d74fdd8a10a4