Loader and loaded item sizes can get unsynchronized

Under some circumstances, it is possible to get the size of the Loader and its loaded item to get unsynchronized (contradictory to the documented sizing behavior )

The attached example is a bit convoluted, but it has been narrowed down from an actual use case, which caused some confusion.

In the example, a Loader is used to dynamically load an item containing a shape: The item has a default size set to the shape's bounding rect's size. The item type is reusable, so it also has logic to scale its shape if the item size is overriden when it is instantiated. This is done in the example, the size of the item is overridden by the Loader.

If you click inside the window of the example, it changes the renderer backend for the shape. The expectation is that everything stays the same except the renderer.

However, if you do run the example and click inside the window, you will see that the shape suddenly gets smaller and it no longer matches the size given to the Loader. In the console output you will see that the item's size and the loader's size now differ.

qml: My width: 119.33095562736466; Loader width: 320

What seems to happen is that the bounding rect updates when the renderer backend changes, and this triggers the original binding for the item's size, even though the size has been overridden in the Loader.

Removing a layer of indirection (e.g. moving the Shape into the TestItem.qml instead of having it as MyShape.qml) seems to avoid the problem, so it seems like very specific conditions are needed to reproduce.

However, as mentioned it did happen in actual application code and if someone should happen to encounter it, the problem or solution are not very obvious.