On certain (large) files I get a SyntaxError in the "Response" tab, see screenhot. Here's a setup to easily reproduce: http://codepen.io/nachtigall/pen/QGvrgm Go to Devtools, Netmonitor, Filter on "XHR". View the "Response" tab of the two XHRs there. N.B.: It's two different SyntaxError Codes, so please check both of them. Happens in FDE 52, but also in today's Nightly 53.
Thanks for the report! Here is what I am doing: 1) Open DevTools, select the Network panel, set the filter to XHR 2) Load http://codepen.io/nachtigall/pen/QGvrgm 3) There are three requests displayed (POST, GET, GET) 4) Select one by one and check out the Response side panel 5) The Response for the last two GETs says: SyntaxError The syntax error for the second GET is there because the response Content-Type: is set to 'application/json', but the actual content is HTML markup. The syntax error for the first GET seems to be BUG. But, it doesn't always fail for me, quite of the the JSON is properly parsed. I've also noticed that the size of the response changes. Are you sure the response is always valid? Honza
Priority: -- → P4
Sorry, about that. I tried hard to make it easy to watch the Errors, so I used jsonblob.com to which I uploaded the files. But this seems to cause other problems... I attached the needed files in "net.zip" now directly. 1. Unpack into a folder that apache can serve. (You need a "proper" server, e.g. "python -m SimpleHTTPServer 8080" did not work for me as it served the JSONs as "text/plain" and not json mimetype) 2. Open the net/test.html in Firefox. 1. Error for project_1.json should be: "SyntaxError: JSON.parse: unterminated string at line 241122 column 154 of the JSON data" 2. Error for project_2.json should be: "SyntaxError: JSON.parse: bad Unicode escape at line 1 column 1310721 of the JSON data" Looking at both JSON files in Chrome under the network's "Preview" tab works fine. I have the files from a real world (Drupal) based project and if you parse them into http://geojsonlint.com/ or http://jsonlint.com/ it says the files are fine... Can you reproduce with net.zop now?
Flags: needinfo?(nachtigall) → needinfo?(odvarko)
(In reply to Jens from comment #2) > Can you reproduce with net.zop now? Yes, thanks! It looks like the response body collected for every HTTP request is limited in this case, which causes the JSON parse error (since the JSON string is cropped). But, this needs detailed analysis. The code that limits response bodies is here: https://dxr.mozilla.org/mozilla-central/rev/34fce7c12173bdd6dda54c2ebf6d344252f1ac48/devtools/shared/webconsole/network-monitor.js#413 Honza
Priority: P4 → P3
Even without changing the response length cut limit, a simple message "message is too long to be interpreted" would be much appreciated over the JSON syntax error - which is a misleading and factually incorrect error message. I ran into this and was trying to find out what was wrong with my JSON. Turns out nothing was wrong. I don't know why the cut limit is in place, or what would be required to change that, but even without changing it, wouldn't it be possible to add an adequate informational message rather than a wrong syntax error?
Status: NEW → RESOLVED
Last Resolved: a month ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1252016
You need to log in before you can comment on or make changes to this bug.