Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.12.7
-
MinGW 64 Bit
-
Windows
-
1a7ca47a7a92945e16006ddd00adea186535cdd5 (qt/qtdeclarative/5.14)
Description
When using a Loader with the asynchronous property set to true and the component to load specified by assigning its URL to the source property, the onSignalChanged signal handler is called twice with identical status value Loader.Loading
import QtQuick 2.12 import QtQuick.Window 2.12 Window { visible: true; width: 640; height: 480 Loader { anchors.fill: parent asynchronous: true source: "qrc:/MyItem.qml" onStatusChanged: console.log("Loader status " + status) } }
Output:
qml: Loader status 2 qml: Loader status 2 qml: Loader status 1
If the code is changed such that the loader uses a local component of MyItem the behaviour is as expected:
import QtQuick 2.12 import QtQuick.Window 2.12 Window { visible: true; width: 640; height: 480 Loader { anchors.fill: parent asynchronous: true sourceComponent: mycomponent onStatusChanged: console.log("Loader status " + status) Component { id: mycomponent MyItem {} } } }
Output
qml: Loader status 2 qml: Loader status 1
In fact, just using MyItem inside the same component as the loader also fixes this bahviour:
import QtQuick 2.12 import QtQuick.Window 2.12 Window { visible: true; width: 640; height: 480 Loader { anchors.fill: parent asynchronous: true source: "qrc:/MyItem.qml" onStatusChanged: console.log("Loader status " + status) } MyItem { visible: false } }
Output
qml: Loader status 2 qml: Loader status 1
It is unclear to me if the signal is somehow emitted twice (but then since the status value remains the same, why is onStatusChanged even called the second time?) or if the loader in facts "restarts" loading the component.
I experienced freezes of my application at startup when using the asynchronous loader in the "problematic" way, however I could not verify wether this is indeed a problem with the loader or a different issue in my application.