Open the suspicious UI, for example, a document tab containing your new property field. If you want to check a document tab as a whole, you need to click through all subtabs and expand all collapsible panels as they contain lazy items. Wait until everything is rendered correctly and close the UI again. This is to ensure that helper components (a context menu, for instance) that are shared between instances and created with the first instance do not blur the view on real component leaks.

Store a snapshot of the current Ext component manager registry by executing the following command in the JavaScript console:

before = Ext.ComponentMgr.getAll()

Open and close the UI again like before. Take a second snapshot:

after = Ext.ComponentMgr.getAll()

In theory, the second snapshot should be exactly equal to the first. But some components are recreated occasionally, which is not bad if their old version is correctly destroyed. Thus, the first check is to simply compare the component count:

after.length - before.length

If there are more components in the second snapshot (positive difference), next goal is to determine their component type (xtype). This is achieved by the following code:

newComponents = after.filter(function(c) {
  return before.indexOf(c) === -1;
})

To get an overview of the new components, count how many components are of which type (xtype), using the following code:

byXtype = {};
newComponents.forEach(function(c) {
  var xtype = c.xtype;
  byXtype[xtype] = (byXtype[xtype] || 0) + 1;
});
byXtype

For custom MXML components, the xtypes in the resulting map indicate the config package, from which you can derive the Maven module, and the config class name, which corresponds to the MXML file name (using an upper case first letter).

Open the suspicious UI, for example, a document tab containing your new property field. Wait until everything is rendered correctly and close the UI again. In addition to what has been said regarding component leaks, this is to ensure that all needed data objects (remote beans) have been fetched from the server. In Studio, remote beans are cached, so they are not garbage-collected on purpose.

Take a heap snapshot. In Google Chrome, this is achieved as follows: In Developer Tools, select "Profiles". Under "Select profiling type", the option "Take Heap Snapshot" is preselected. The third option, "Record Heap Allocations", claims to be suitable for isolating memory leaks, but CoreMedia founds comparing heap snapshots simpler. Press the button "Take Snapshot". In the left column, Chrome adds an icon for the snapshot and shows a progress indicator while it is recorded. When recording is finished, the heap snapshot is shown as an expandable list of all JavaScript objects is shown, grouped by their (internal) type.

Repeat opening and closing the suspicious UI like in step 2.

Take a second heap snapshot. To do so, either you have to select "Profiles" on the left and proceed like in step 3, or simply click the "record" button (a gray filled circle).

Where the label "Summary" is shown, you can switch to "Comparison". The first snapshot is automatically selected for comparison. Now, you no longer see all objects, but only those that either have been removed ("Deleted") or have been created ("New") between snapshot one and two ("Delta").