When the default choose dialog definition is provided by the ContentApp class, a large portion of the default sub-app's configuration (browser typically) is applied to it. However, we do not make the choose dialog component provider aware of that sub-apps bindings: the "parent" component provider passed to choose dialog presenter is the one of the app, and only its UI context is considered.

Luckily enough, that does not cause troubles in the default case (like EE webapp without extra mods), since the current IoC mechanism arranges the bindings so that they are easily accessible without extra context required as long as there's no ambiguity (e.g. several context-specific implementations of the same interface).

So it happens that e.g. the commerce tools integration brings in the alternative implementation of e.g. TreeView which already prevents any choose dialog from starting!

In order to fix the problem we need to expose the default sub-app bindings to the choose dialog component provider. Thanks to the new light-weight component providers, that should be not hard at all.