This just stopped working

[tandrewnichols]

This extension just stopped working for me today. It's worked brilliantly in the past. I'm not sure if anything's changed on my end. Curious if you know of particular settings or updates that don't play nicely with this. Or just in general, any way of figuring out what's happened.

[tulios]

Hi @tandrewnichols, last update shouldn't have caused the problem. This extension might crash with others since it analyses the page content, can you try to disable other extensions? Can you also check if there is any error in the console?

Thanks, and sorry for the trouble!

[tandrewnichols]

I did check the console already, nothing there. I haven't added any new extensions recently. Meaning, it was working with the setup I have now, and then stopped working (unless one of my other extensions updated behind the scenes maybe). I'll try disabling a few to see if I can figure anything out. I've tried this in Chrome Canary version 57.0.2939.0 canary (64-bit) and in regular Chrome version 54.0.2840.98 (64-bit), in case that makes a difference.

[tandrewnichols]

I disabled every other plugin I had and reset the default options on json-viewer, and I'm still getting regular json (the way the browser normally displays it without a plugin). It's like json-viewer isn't intercepting it. I've tried a couple other json view plugins as a test, and they are working correctly.

[tulios]

Ok, can you do a last test? Disable and enable the extension. If it doesn't fix the problem, can you share an example of page you are trying to highlight?

Thanks for the debugging.

[tandrewnichols]

I've tried that already, as well as removing and reinstalling the plugin. Not sure I can share the page I'm trying to highlight. It's running on localhost.

For background, my common use case for using this plugin is in development of the website of the company I work for. We have a development feature that returns the json used to render the page instead of the page itself (for internal/admin users). The page I'm looking at now is 11.9KB as json. I can give you a sample snippet of the json if that would be helpful, but . . . I don't see how it would be. I mean, json is json right?

[tandrewnichols]

Something else just occurred to me. I think the plugin is attempting to do something because I also installed "JSON Formatter" to use in the mean time until I figure out the issue with this, and if I have both of those plugins turned on at the same time, JSON Formatter does add it's normal buttons to the top of the page, but it doesn't format the JSON. You have to click "Raw" and then click back to "Parsed" to get it to format. When only JSON Formatter is on, it comes up parsed right away. So this plugin is doing something to the payload (because it prevents the other plugin from rendering correctly).

Is no one else having any issue with this? I wonder if particular Chrome settings could be a problem...

[tandrewnichols]

A little more information on this. A colleague and I just discovered that this extension works fine when used at the root of a domain (e.g. for us localhost:8000), but not on any path (e.g. localhost:8000/foo). He's having the same experience with the plugin, btw. Which still doesn't necessarily mean it's an issue with the plugin, as we are both working on the same site.

[johndorn]

:+1: am said colleague

[benvan]

I wonder if I'm experiencing something with the same root cause. Extension fails spuriously for me, but I've narrowed it down to the situation where the JSON in the document is actually split (for reasons I still haven't managed to understand) over two text nodes.

Though I'm not sure why Chrome decides to split the text sometimes (it's not a length thing, it seems to depend on the content), it seems like a reasonable thing for it to do. Since they're adjacent text nodes, each node has the same wholeText attribute - I might submit a pull request to cater for this situation by comparing adjacent nodes.

Anyway - if you guys think this might be the issue you're facing, open up devtools on a page that fails, and see how many elements are listed in document.body.childNodes. If it's more than 1, there's your problem.

[benvan]

Following up on the above, here is a pull request: https://github.com/tulios/json-viewer/pull/133

[Archomeda]

I'm having the same issue. I'm working with the Guild Wars 2 API, and for example this data does not always get parsed with json-viewer. It takes a couple of refreshes before json-viewer picks it up. Basically it works half the time whereas it used to work every time.

[tulios]

@Archomeda, the next time it fails can you save the response? @benvan created a PR to fix this problem and we can use this payload to further test the PR.

Thanks for all reports, it will be really nice to fix this :)

[benvan]

@Archomeda, in addition to saving the response, please check the number of text nodes that were created by the browser as detailed a few comments above. This will let us know if it is the exact same problem - I would hazard a guess that the conditions in which a response gets split on display might vary between browser installations

On Fri, 13 Jan 2017, 08:23 Túlio Ornelas, notifications@github.com wrote:

@Archomeda https://github.com/Archomeda, the next time it fails can you save the response? @benvan https://github.com/benvan created a PR to fix this problem and we can use this payload to further test the PR.

Thanks for all reports, it will be really nice to fix this :)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/tulios/json-viewer/issues/126#issuecomment-272387003, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXqDfefrMK-9h_RPtK4YFR0FClLmKjlks5rRzSMgaJpZM4LEsrg .

[Archomeda]

I was about to respond with about how this endpoint is not the only endpoint it's failing on, and that it even fails on the root endpoint. And that only outputs:

["v1","v2"]

But, then I thought this was kind of odd. Especially since I compiled the PR and tried to see if it was fixed. It was not. Then I went to check if I had any conflicting extensions. And apparently I have, since Incognito worked correctly.

I installed this extension recently, and this seems to be the cause of my issue. Or rather, the setting to replace all emojis with EmojiOne is causing a conflict.

Sorry for the confusion I caused since my issue is essentially a different problem. I assumed mine was the same when I saw this issue here.

[tulios]

If other extensions change the body it will prevent json-viewer to highlight, the current implementation is super strict about which content should be highlighted, it only highlight "blank" pages from chrome. Basically pages with one pre node or, recently, one text node. If you have any ideas for this check feel free to share, @benvan PR will greatly improve this.

[tandrewnichols]

@benvan @tulios I've just checked on a page where this plugin doesn't work for me, and document.body.childNodes only has 1 element (a pre). Also, just to rule it out, the extension does not work in Incognito mode with all other plugins disabled. As I mentioned before, it does still work on the root page (/), but not on any page with a path (/foo).

[tulios]

@tandrewnichols can you provide the payload so I can debug what is happening?

[benvan]

@tandrewnichols can you check the number of nodes inside the pre? edit: Sorry, don't worry about this - I've discovered it's irrelevant.

[benvan]

@tandrewnichols it would be great to see the json body that breaks it for you. If it's sensitive data, you might find the following script useful which redacts all text content into x and 9 while preserving structure and length:

cat broken.json | sed -e 's/null/0000/g' -e 's/undefined/000000000/g' -e 's/[a-zA-Z]/x/g' -e 's/[0-9]/9/g' > broken_and_redacted.json

[tandrewnichols]

It doesn't seem like there should be anything different between my working and non-working pages, but I've created this gist: https://gist.github.com/tandrewnichols/8e37e24ddcc6f8f38c5b28de0470babe

Note that (again) the working one is always on /, while every other path produces non-working json (though not always identical to what's in that gist), regardless of other variables within that json (as far as I can tell).

I actually am not sure if there's anything sensitive, and as it's like 2000+ lines (when formatted), I decided to go ahead and "redact." Nice trick, btw.

[benvan]

@tandrewnichols Thanks for the data. I've had a dig around, and it's a bug that stems from json-viewer getting confused with the part of your payload that has a large blob of stringified json in the json (it's line 1197 of your gist)

@tulios The bug is in wrapNumbers - it produces incorrect json. I'll spend the next 20 minutes to see if I can fix it

[benvan]

Simple breaking example:

{
  "broken": "{\\\"99\\\"}"
}

It looks like the wrapNumber function is fairly fragile - it breaks here because triple backslash is used which it doesn't expect. I wonder if there's a less fragile approach to retrieving the original numbers? I could imagine one alternative being a normal JSON.parse, followed by a traversal down the tree, peering into the original string every time a number is encountered. In the case where the numbers differ, and offset can be incremented so that the pointer in each source stays in sync.

Any thoughts?

edit: On second thoughts, the above is not so simple - we can't reliably expect the original text to not contain weird formatting / extra whitespace characters. In the general case it's probably easier to just write a custom parser. I'll give it a quick go - my main concern would be awful performance...

[tandrewnichols]

So is it trying to parse that string as JSON? The triple slashes occur when we have (I know, I know) stringified JSON inside stringified JSON, but rendering the whole string as a string seems sufficient. I don't think it needs to be parsed.

[benvan]

You're right, it doesn't need to be parsed.

The reason it actually gets parsed is because json-viewer appears to have a feature which attempts to display numbers in json as they were originally written. That is, it attempts to prevent 0.0 being turned into 0 by JSON.parse

I've only just looked at the source, so take this with a pinch of salt, but the way json-viewer does this is by operating on the string representation before it gets parsed, turning numbers like 0.0 into the string "0.0". Of course, it shouldn't do so if that number exists inside a string. That check appears to be broken, and it functions by tracking open and close quotes in the unparsed json.

On Fri, 13 Jan 2017, 19:31 Andrew Nichols, notifications@github.com wrote:

So is it trying to parse that string as JSON? The triple slashes occur when we have (I know, I know) stringified JSON inside stringified JSON, but rendering the whole string as a string seems sufficient. I don't think it needs to be parsed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tulios/json-viewer/issues/126#issuecomment-272526383, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXqDTygKEd7XwlcOq0qpXpWQGjWZ2y1ks5rR9ETgaJpZM4LEsrg .

[benvan]

Fixed: https://github.com/tulios/json-viewer/pull/134

Andrew, just FYI - it seems the reason for the extra parsing is not so much about '0.200', but more for preventing long numbers being converted into exponent form, and losing accuracy.

Mind you.. I do wonder whether that's a good idea. Although it's useful to see the original number, I can imagine situations in which this causes a serious case of the head-scratch, where the json looks fine but the program you're writing produces "incorrect" values.

It would be useful to know that JSON.parse actually results in a different number to the one displayed on the screen. @tulios - is it worth making this obvious somehow?

[tulios]

Version 0.16.2 is out, I'll keep this open until it is properly rolled out. Many thanks for the discussion and debugging!

@benvan JSON can be used between two backend systems, let's say one in Java and another one in C++, both languages support higher numbers and when visualizing their payloads we shouldn't apply the limitations of javascript since they are not using javascript anyway. There is no max number in the JSON definition but on the languages using JSON.

[benvan]

Ah, you're right - that's a very good point :)

[farmisen]

same thing just happened to me for what looks like another reason and in my case it was the ghostery extension that was breaking json-viewer. White listing my development site in ghostery didn't fix it and I had to use the following other extension to prevent ghostery to run when I am hitting the api I am working on: https://chrome.google.com/webstore/detail/extension-automation/ghopjgdkodchjclkkfdekhjfomdbakkb