[Development] Feature freeze exception for QTBUG-95587

[Ulf Hermann]

Hello,

due to the magnitude of the above mentioned bug, I'm considerng to 
introduce a new feature in Qt 6.2.1. The new "@" operator in QML 
relieves you from typing "Qt.resolvedUrl" over and over. See 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/369987

Now the question is whether we want to relax the feature freeze for this 
particular issue or not.

Some background:

In Qt5, the QML engine resolves a relative URL as soon as it is assigned 
to any property of type "url" or QUrl. This means that you cannot store 
relative URLs in such properties, and reading such a property back in 
QML gives you a different value than the one you have written. The base 
URL used for resolving is the URL of the QML document where the 
assignment happens. This is often not the place where the URL is meant 
to be resolved. There were a number of bug reports about these 
shortcomings in Qt5, especially when combined with URL interception 
and/or redirection. See for example QTBUG-81244 QTBUG-88965 QTBUG-66690 
QTBUG-76879

In Qt6, URLs are simply not resolved anymore when assigning them to a 
property. This conveniently gets rid of all the cruft and inconsistency 
resulting from the Qt5 behavior. Instead the individual elements using 
URLs (Image, ShaderEffect, ...) are free to resolve them to their 
liking. There is suitable functionality exported from QtQml to do that.

Now, there is one problem, QTBUG-95587: The original context where a URL 
was first assigned to a property is not easily available to the final 
consumer of the URL. At the same time, the element consuming the URL 
might be deeply nested in the implementation details of some module and 
might have a rather internal base URL. In this case, the URL as resolved 
by the consumer is not very useful.

A user can fix this by explicitly calling Qt.resolvedUrl() in order to 
resolve the URL in a specific context and make it absolute. As we need 
URLs rather often in QML, we will see much more Qt.resolvedUrl() in Qt6 
than we have seen in Qt5. As Qt.resolvedUrl() is quite a mouthful, there 
should be a shorthand for it: the '@' operator.

So, is this bad enough for an exception, or should we rather live with 
Qt.resolvedUrl() in 6.2. I'm tentatively in favor of the exception 
because 6.2 is a rather important release and this is a rather ugly wart 
in the QML language.

best regards,
Ulf