Component defined in an extended QML file not reporting with the name of the file for autopilot

[Arthur Mello]

Component defined in an extended QML file, without adding any new property, will report to autopilot with the name of the base QML component instead of the same name of the QML file. When we define some new property the component will report as the file name, as expected.

This can be check with the sample code added here lp:~artmello/+junk/autopilot_issue. The "RedRect" component will be defined as so when investigating the code with autopilot3 -vis. But the "BlueRect" will be found as an usual Rectangle component.

We can always rely on the objectName, that will work on this case. But this behavior leads to unexpected issues when writing emulators.

[Christopher Lee (veebers)]

This isn't solvable within autopilot. The Qml processor contains an optimisation where, if you don't specialise your type with a property, it will use the parent type name. That's why, in your example, you get 'RedRect' (the name of the parent type) but 'Rectangle' for the BlueRect due to the property is enabled or not.

[Olivier Tilloy (osomon)]

Confirmed by adding a print statement in Component.onCompleted for the component, printing the value of 'this'.

In the case of the NewTabView component, which has custom property definitions, "NewTabView_QMLTYPE_113(0x1cbf700)" is printed, whereas for the NewPrivateTabView component, which doesn’t have properties, "QQuickItem(0x432a9a0, "newPrivateTabView")" is printed.

This is not an issue in autopilot, it’s rather a side effect of an intended optimization in QML, so I’ll mark this bug invalid.