Recently updated VS Code + PHP XDebug - Disable 'auto expand data' arrays/objects

[ChameleonDevil]

NOTE: I originally applied this on stackoverflow, and as requested by zobo
Please see at the end (screenshots/info) for more information that I added additionally here

I also believe that the following is 'related' in some way (crashes/slow performance for hover): While debugging, hover tooltip takes 3 seconds to show, as although I do not get 'slow hover', I get 'huge object output, which might cause VS Code to crash

A recent update (not sure which, I updated yesterday since cancelling updates since end last year) of Visual Studio Code changed behavior of PHP Debug from XDebug (or even with PHP Tools extension from DEVSENSE) now has this 'auto-expand-data' feature, where arrays and objects now shows their values inline of the array/object, which in the case of Magento 2 makes debugging extremely cumbersome now.

**I should have just not upgraded!!!

• The VS Code would crash more often now when large objects are displayed, because it now wants to auto-expand every single private variable for a Magento 2 object as well

• Since the extended feature 'auto-expands' variable values, it is not really clear anymore which are private/protected/public values any more.

Which recent settings are added, and how do we disable this?

Example

New:

> 0:array(2)
0:"price"
1:"ASC"
> 1:array(2)
0:"name"
1:"ASC"
> 2:array(2)
0:"attr1"
1:"ASC"
> 3:array(2)
0:"attr2"
1:"ASC"
> 4:array(2)
0:"attr3"
1:"ASC"

Old:

> 0:array(2)
> 1:array(2)
> 2:array(2)
> 3:array(2)

Clearly the 'old way' (before updating VS Code today) is more concise and easier to read, I am giving an array example, since Magento 2 object would just cause VS Code to crash (so can't show an exact example).

It's even worse for objects, viewing (while debugging) any Magento 2 object now spans 1000s of lines, and VS Code will crash almost everytime)

I don't need this feature, and would rather just want to access and view values as I need them from functions/variables:

For instance, when I would get $this->getCollection() from terminal now, I would get 1000s of unneeded values (private things expanded).

In debug terminal

// First find out what Collection is
$this->getCollection()

// Now since Collection processed filters, I might want to investigate `getSelect`
$this->getCollection()->getSelect();

// Also investigate 'from'
$this->getSelect()->getPart('from');

How can I disable this feature?

Additional information

TonyG mentioned this in the comments as well, which I forgot to mention (as I just gave information on terminal command view), but this also happens to me.

The Watch area shows correct tree structure. It's the mouse-over on variables in code that is problematic.

VS Code version:

Version: 1.64.2 (system setup)
Commit: f80445acd5a3dadef24aa209168452a3d97cc326
Date: 2022-02-09T22:02:28.252Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19043

PHP Debug (Xdebug) v1.24.2

Last updated 23/02/2022, 09:00:55
Identifier xdebug.php-debug

XDebug on Server: (Ubuntu 20.04)

Zend Engine v3.3.21, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.21-1+ubuntu20.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v3.0.3, Copyright (c) 2002-2021, by Derick Rethans

Screenshots & Extra Code samples

For more information: show_hidden 1 or 0 does not change the output, I just wanted to confirm if this is perhaps the output that changed (I do not know all the xDebugSettings variables!).

// launch.json file of VS Code
            "xdebugSettings": {
                "max_children": 100,
                "max_data": 1000,
                "max_depth": 3,
                "show_hidden": 0
            }

$this Discussed here in the screenshots is of type Magento\LayeredNavigation\Block\Navigation

Image 1

• Sample of hover (please check other images from terminal for more information-while scrolling, not crashing/stutter is slightly more prevalent.

Things of note here:

Take note of the size of the scrollbar, there are literally 1000s of entries here now.

Image 2

• Terminal output on VS Code for $this at line 299. Same type as the hover image.

Things of note here:

_underscoreCache is an array(43), and if you count those values below the array, they are exactly 43 (it does not show indexes, since its not a multi-dimensional array).

Image 3

• Terminal output of same $this object, but scrolling down, partially showing _underscoreCache and then showing _catalogLayer and then _underscoreCache

Things of note here:

Magento 2 shares alot of information on objects, so for instance _underscoreCache is part of $this, also $this->_catalogLayer, so now that array _underscoreCache **inside _catalogLayer is also expanded by its 43 items.

Image 4

• Terminal output of the same $this alot downwards, and factories is array(7), and the array entities are auto expanded showing the object types (7 items).

Image 5

• Terminal output of the same $this, further downwards, showing filterTypes (array(4)) expanded, same for `filters (array(32))

Summary

1. The recent changes (with some visual improvements - for instance Tree-like indented output would be extremely useful for smaller objects to auto-show their array contents. I think if it is indented more, it should be easier to see which 'level' you are on.

2. However, for overly large objects (like most Magento 2 objects are...), this auto-expanded feature makes it extremely hard to find the information you need..... scrolling through 1000+ lines for the same object, and hoping it does not crash VS Code.

• Smaller objects: Would be perfect when indented tree like view
• Larger objects: Crash-prone, and makes debugging extra confusing.

[zobo]

Hi Thanks for the report. I'm looking into it and I think I already found something... I'll let you know if I need more info.

[zobo]

Can you try to install version 1.24.0 ? I think there is something I broke.. badly. You can select a specific version by using the context menu in VS Code.

[ChameleonDevil]

Thank you @zobo, good luck in finding the issue!

EDIT:

You must have replied exactly when I posted. Sure will try that quickly

[ChameleonDevil]

@zobo A quick installation of 1.24.0 seems to have a much better result! It feels smoother as well (but I guess my original post that it was related to slow hover takes 3 seconds is something else, since it seems these two new versions were rather recent.

Comparing Image 1 above (showing _underscoreCache) vs the result now, on v1.24.0, a clear difference and much more condensed.

Hover:

Terminal:

[zobo]

Ok. I am pushing out a fix. I have to run right now, but will come back soon and explain the problem in more detail.

[ChameleonDevil]

Wow thanks so much for the quick update! Talk to you later when are available.

[ChameleonDevil]

I can confirm that the new version 1.24.3 resolves the issue as I have installed it just now.
Thank you @zobo

[zobo]

Ok, a "post mortem". The problem was introduced in the last two versions (released more or less at the same time) while trying to solve traversal of property structure with extended fields. Here is the structure. If you look at the code change here I replaced childNodes with getElementsByTagName. Rookie mistake, as we all should know that the second function finds also all NESTED elements with that tag.

So what I can see in you screenshots is that the whole tree of properties was flattened up on the first level. Since you also had max_depth set, all those levels got merged up. This is why you see 1000s of entries instead of max 100 as defined by max_children.

Thanks for reporting.

[ChameleonDevil]

Again, thank you very much for the quick updates and fix, all I did was report the problem!

I was just extremely confused yesterday when I got so many values (flattened as you mentioned), and even thought I created a huge bug to 'duplicate' objects with recent changes I applied. After that, I tried to figure out if any new variables were introduced, but couldn't find any.

I usually go max_depth 4 when needing to investigate deeper, but then everything slows down alot. max_depth 3 works best for Magento 2, performance vs objects visible compromise.

[zobo]

You could also leave it at max_depth depth 1 and VSCode will fetch the lower level when needed.
This does not yet work for "eval", but hopefully Derick and I will get to that too soon.

[TonyGravagno]

Verified that v1.24.3 is absolutely beautiful (again) :)
BTW, this was affecting the vars in the watch window too. I guess I didn't see that with earlier data.

Thank you SOOOO much for handling this so quickly - in this great FOSS world sometimes we need to wait for months or years for irritations like this to go away. Not this time. And our coding now continues...

[derickr]

@zobo For doing this for eval, PhpStorm uses a neat trick. Instead of doing just the eval value, they do:

eval( '$GLOBALS[\'eval_cache\'][$uuid] =  .... );

And then use the eval_cache to query further into the properties. I know because they had a bug in it: https://bugs.xdebug.org/view.php?id=2053

[derickr]

This test case shows how it works in more detail:
https://github.com/xdebug/xdebug/pull/816/files

[zobo]

Ugh.. I did not think of this hack... However I would much rather have Xdebug have a local copy of evaled zval until a step operation happens...
Any idea if PhpStorm also clears this?

I'll try to find time to test an implementation...

Thanks!