geoelectric
commented
4 years ago Forgot I filed this previously, apologies for the dupe I just closed.
I've found the problem, and will submit a PR or possibly fork the project, if there's no further movement, as I do need the nested JSON behavior to function, for work. However, in case I'm hit by a bus:
https://github.com/dardesantis/DJSON-Viewer/blob/master/extension/js/content.js#L284
...has window.djson being the object that's sent into the background.js handler. However,
https://github.com/dardesantis/DJSON-Viewer/blob/master/extension/js/content.js#L294
...the thing that sets up the djson object in-console doesn't parse the input to a window.djson intermediate object and alias that to djson when doing inline formatting. Instead it builds a window.djson={{input string}} intermediate code string inside a constructed script element, and separately and directly parses the same input string out to djson.
I'm unsure what's going on with the constructed element and the window.djson assignment innerTexted inside it. From the console after loading an inline-formatted page, window.djson is in fact defined. But in the click handler for Nested Json, window.djson is undefined in content.js runtime at the time of the L284 breakpoint, though djson is defined. Changing the code just-in-time at breakpoint to send djson instead of window.djson causes the nested JSON functionality to work as expected and open a new extension tab with the nested part.
So window.djson being undefined and getting sent to background.js does seem to be the problem.
Depending on whether or not the local djson variable seen by code at L284 is completely tied to having an open console/debug session (doesn't look like it) then that's a possible fix, and the one I'd submit as a PR. If window.djson should be defined at L284, fixing that is the other possible avenue, though not the one I'd tackle because the use of that script element is not straightforward and I wouldn't want to break it.
I could swear this worked until fairly recently. When I plug JSON directly into the extension popup dialog and display it, the "view Nested JSON" buttons work as expected. But when it kicks in as a response formatter when retrieving a JSON-like response from a URL, they don't.
Inspecting with dev tools shows that when the extension creates the page, there are onClick event handlers (among others) that handle those buttons. When the response is formatted inline, there are not any event handlers. That being said, the raw/parsed, expand/collapse, options buttons all work, so the original Callum Locke options bar still functions. It's only the stuff inline to the content.
I couldn't find a public URL with nested JSON to test, but I used the following literal both pasted in, and served from a local textfile with
python3 -m http.server:If, for some reason, it turns out you can't put active decorations on displayed text files anymore (i.e. can only attach JS to HTML, etc) you might consider an inline expansion a la the one done by Nested JSON Object Parser.
It just displays the subobject in place of the text values as if it weren't a nested string. That has its own issues because they don't have any way of controlling it or showing you they did that, but you could add an "expand embedded JSON" toggle button to the original options bar and maybe hint in the gutter.
Unfortunately, it's a sloppy fork (looks like a personal project) and they haven't posted their own URL while the metadata still points at the Callum Locke repo. So their code and licensing isn't readily available, but I assume it's pretty straightforward to rewrite the response.
Honestly, I'd prefer that flow over the new page for every nest flow we currently have. That one is a bit painful, especially since reloading the page by mistake breaks it. The files I'm practically having to use this on have multiple levels of nesting, so anything recursive is far easier.
Edit: should clarify, this from the Chrome Web Store, using version 0.6.0. The Chrome version is Version 81.0.4044.122 (Official Build) (64-bit) on Mac.