show prototype chain of JavaScript objects in the inspector

[skybrian]

When looking at a native JavaScript object, it's often important to walk the prototype chain. A web browser will typically show a special field named "proto" that you can open to see the prototype. These proto fields seem to be missing in sdbg.

Note that the GWT compiler will hoist immutable fields into the prototype chain (to reduce the size of instances), so this is useful for Java objects as well.

[ivmarkov]

That's a fair point. I already received a complaint from another user that the proto field is missing - will look into it.

[ivmarkov]

Good new: proto and the global state are hidden because of code inherited from Dart. Apparently, Dart treats those in a special way and displays those in custom views which are removed from SDBG.

I'll re-enable the visualization of proto and the global state over the weekend.

[skybrian]

Be careful about global state. GWT has so many global variables that it's a big performance hit when stepping through code, so it's not a good idea to display the variables by default. I think it would be better to have a way to search them (perhaps with autcomplete) and display only the ones you need.

Also, since GWT code is usually in an iframe, there are two windows to think about. Perhaps the top-level window might be okay, but I still think it should be evaluated only on demand for good performance.

[komasoftware]

In chrome devtools, the global state is displayed as a collapsed node in a tree view. I know by experience that accidentally expanding this node from a GWT application can make chrome crash, or at least become unresponsive for minutes. But the collapsed tree solution gives the end user the freedom to inspect the global state if he is prepared to take the penalty. So the tree view can be a good trade-off between showing and not showing.

[skybrian]

Yes, that is certainly a good start and perhaps good enough for now.

However, if the user leaves the tree expanded, I would guess that stepping will be much slower (since the list has to be sent again over the network) and they might not know why. This is the sort of problem solved by UI frameworks like React. Perhaps a diff could be done and then only the changed variables need to be updated?

But then again, perhaps it's not the best UI experience in the first place. Why does anyone want to wait for a very large list to load and then scroll through thousands of variables?

Another possible solution: when Chrome renders a large array, it makes a tree with subranges as internal nodes, such as [0..99], [100..199] and so on. This at least helps skip the rendering part.

[ivmarkov]

This is now implemented. In addition, there is a UI to control:

• Whether the proto variable is displayed (by default: yes)
• Whether functional values are displayed (by default: no)
• Whether the global state is displayed (by default: no; if set to yes, a waring dialog appears)

There is an annoying persistence problem with the above settings, however I'll open a separate issue for that.

[ivmarkov]

The above will be available in the 1.0.3 BETA release which will be available shortly.

[ivmarkov]

BETA release with the described features available here: http://sdbg.github.io/p2beta/

[ltearno]

Hi Ivan,

I just tried your field name Javaifier and the prototype chain showing and it really rocks ! Thanks a lot for developping this,

We can now inspect java fields easily and still see the "metal" javascript, great !

Still when the class names will be here, that will be even more perfect !

Arnaud

Le Wed Jan 21 2015 at 17:45:09, ivmarkov notifications@github.com a écrit :

BETA available here: http://sdbg.github.io/p2beta/

— Reply to this email directly or view it on GitHub https://github.com/sdbg/sdbg/issues/102#issuecomment-70872653.

[ivmarkov]

@ltearno - thanks. But the class-names are there? I mean the short ones? You should see stuff like "DialogBox", "HandlerManager" etc. etc. in the Variables view. Or do you want to see the full class names, e.g. com.google....DialogBox etc? This is not a problem, I can create an option for that...

[skybrian]

In suberdebug I made it a pseudo-field. The last field in a Java object is "<class>" and the full class name. I think it's less clutter that way.