1224071 - [non-e10s] JSON view is unreliable on huge (~2Mb) JSON files

Status: RESOLVED FIXED

(DevTools :: JSON Viewer, defect, P2)

Description

[arni2033]

Attachment: screenshot 1 - [non-e10s] JSON view always returns error on huge JSON file.png

STR:   (Win7_64, Nightly 45, 32bit, ID 20151108030417, new profile)
1. Set pref   devtools.jsonview.enabled -> true
2. Open this 2Mb JSON attachment from bug 1122483 in a new tab:
>   https://bugzilla.mozilla.org/attachment.cgi?id=8656886
3. Repeat this 5 times: click "reload" button or press Ctrl+R.

Result:
 In non-e10s mode JSON viewer fails at Step 2 and fails 5/5 times in Step 3.
 In e10s mode JSON viewer works OK at Step 2 and OK 5/5 in Step 3.

Expectations:
 Non-e10s performance should be at least 1/5   (lol)

Note:
 I tried to copy "Raw data" and compare it to original file .
 JSON viewer appears to make mistakes like turning this fragment
>   {"someInnocentName":"blah", "anotherName":1.234567}
 into this one
>   {"someInno:1.234567}

Comment 1

[Bryan Clark (DevTools PM) [:clarkbw]]

Thanks for reporting this arni2033!  e10s is the future for Firefox so I don't think this is going to get any priority attention as it works in e10s.  But lets keep the bug open for a little while longer so we can do some more testing.  

Let me know if you further insight or suggestions.  Thanks.

Comment 2

[armisael]

I fear this is not related to e10s; I have it enabled and struggle with the very same bug ("biggish" jsons served by elasticsearch). I tried disabling it, and still.

Comment 3

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

In my testing with e10s off, I sometimes get:

SyntaxError: JSON.parse: unexpected character at line 1 column 459164 of the JSON data

in JSON Viewer using the attached example.

So far, with e10s on, it always works.

:armisael, can you describe your test with e10s in more detail?

Comment 4

[armisael]

Sorry for the late reply; my test is very simple: I'm using firefox with e10s enabled, and when getting big documents from an elasticsearch cluster I often got the SyntaxError; today I worked on creating a big-json example to send you, and well, I couldn't reproduce the bug, even on those big documents I was referring to.

Apparently the latest version of firefox fixed the issue (I'm currently running on 46.0a2 (2016-02-01)).

Comment 5

[armisael]

Hi all,

In the last few weeks this stopped happening, what about you?

Comment 6

[arni2033]

>>>   My Info:   Win7_64, Nightly 48, 32bit, ID 20160330030326
I completely confirm my comment 0, including percentage in both modes
This bug looks like some race condition that _may_ rely on slow ipc or some e10s bug (of course I cannot be sure about that). So an investigation may still make sense.

Comment 7

[vm]

After I updated to latest Firefox:  53.0.2

I'm experiencing the same issue (mentioned in OP - Notes  section).


I can't post the data url or contents as it's company data.

Here are the headers returned from server.  This is an ODATA fetch (requested with $format=json query param) coming from Microsoft Dynamics Nav  (an ERP system).


HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 2876348
Content-Type: application/json;odata=minimalmetadata;streaming=true;charset=utf-8
Server: Microsoft-HTTPAPI/2.0
X-Content-Type-Options: nosniff
DataServiceVersion: 3.0;
Date: Thu, 11 May 2017 16:08:55 GMT



After making 5 consecutive requests, the JSON viewer fails to parse the JSON at random locations each time, even though the data did not change.  An inspection shows the same EXACT issue described in the Notes section in the first post in this thread.

If you inspect the raw source in the json viewer, you see that it appears that small chunks of data "disappeared" - and that of course results in unparsable JSON.

Note that if I request  view-source:url,  the entire  string displayed is correct and parseable json... and different from what shows in the RAW tab in the json viewer, the latter showing JSOn with missing chunks as described above.

Comment 12

[Oriol Brufau [:Oriol]]

This should have been fixed by bug 1367894.