One potential issue i have observed appears to come from the use of the selectmenu widget. I have managed to reproduce the behaviour seen in a stripped down codepen:

https://codepen.io/garycuthbert/pen/xNzdPZ

If you 

1. Run the code pen under chrome, open the chrome developer tools and take a heap snapshot before interacting with it.

2. Click 'Create ComboBox' to confirm one appears.

3. Click 'Remove ComboBox' and confirm it disappears.

4. In the chrome memory tools, collect the garbage (dustbin icon) and take a second heap snapshot.

5. On the second heap snapshot in summary view select compare 'Objects allocated between Snapshot 1 and Snapshot 2' and type 'Detached' into the display filter you will see an entry for 'Detached HTMLSelectElement', if you expand this and hover over the 'Detached' text in the list you will see 'select.soloComboSelect' which corresponds to the <select> node added to the DOM in the function 'showCombo'

My initial investigation showed detached HTMLOptionElement items corresponding to the option elements created under the <select> node. 

To clean up this issue in the 'destroyCombo' function i explicitly remove the options from the <select> node and call 'selectmenu('refresh')' to re-render an empty combo box before calling 'selectmenu('destroy') to remove the whole thing however I still see the detached <select> element.

If i explicitly remove the <select> element from the DOM before calling selectmenu('destroy') i get an error from the widget when i subsequently attempt to destroy it.

If i explicitly remove it afterwards i can observe the DOM element being removed (if i set a breakpoint in the code) however it is still listed in the memory heap as detached.

Is there a correct way/order of destroying a selectmenu and the DOM entries required to render it? or could it be a bug in the widget itself?

Thanks for reading, any help/pointers will be much appreciated