The problem here is regardless of height-for-width scenarios, the MxScrollView needs to detect
feedback cycles generated when allocating a child that almost fits the scroll view allocation.
Usually this recursion is caused by some latent process involving scrollbar display, but
might not be the case here:
o scroll view allocates size
o Child receives allocation and updates adjustments
o scroll view parent decides to show/hide the scrollbars
o showing/hiding the scrollbars causes yet another relayout to be queued...
This cycle above is only a double loop in most cases where the unsuspecting scroll view
allocates a size that is well below or above the child requested size (in which case a single
scroll bar is visible after 2 allocation cycles).
This is a separate issue as the one reported in https://github.com/clutter-project/mx/issues/57
The problem here is regardless of height-for-width scenarios, the MxScrollView needs to detect feedback cycles generated when allocating a child that almost fits the scroll view allocation.
Usually this recursion is caused by some latent process involving scrollbar display, but might not be the case here: o scroll view allocates size o Child receives allocation and updates adjustments o scroll view parent decides to show/hide the scrollbars o showing/hiding the scrollbars causes yet another relayout to be queued...
This cycle above is only a double loop in most cases where the unsuspecting scroll view allocates a size that is well below or above the child requested size (in which case a single scroll bar is visible after 2 allocation cycles).