[Development] Requesting a break in behavior in QML Text element

[Alan Alpert]

On Fri, Jan 30, 2015 at 1:59 AM, Rutledge Shawn
<Shawn.Rutledge at theqtcompany.com> wrote:
>
> On 29 Jan 2015, at 23:46, Olivier Goffart <olivier at woboq.com> wrote:
>
>> On Thursday 29 January 2015 23:24:51 Robin Burchell wrote:
>>> tl;dr: I'd like to request a behavior break in QML's Text element. I
>>> would like to change the default value of Text::textFormat from
>>> Text.AutoText to Text.PlainText.

Actually, the default should be Text.StyledText. It contains the core
features of RichText without the big performance hit.

>> Personally, that's what I am doing in the QML project I am working on
>> (We had to develop our own set of component (it was started before QtQuick
>> controls), and the text component default to Test.PlainText)
>>
>> Given the security implication, I do believe PlainText should be the default.

If you're using user-generated values you should certainly set
PlainText (until we have remote references disabled), but it's not the
common case for Text. It's the basic element used to put your UI text
on the screen anywhere in the app.

>>
>> However, I think it's too much of a breaking change for anyone who has used
>> html tags on purpose and did not explicitly set the format.
>>
>> Is it possible to do the change if we do
>> import QtQuick 2.5
>> That is, the default of textFormat changes depending on the number in the
>> import statement.
>
> +1 to that.  If you update your import versions, you can expect some minor changes; and if you are editing the QML anyway, it implies that you are ready to take the time to re-test your application and make small fixes and improvements.

I agree in theory. The biggest concern of changing the default value
is if the runtime updates underneath your application and breaks it
(super bad!), so if we can tie the change to a new import version then
we avoid that scenario while helping new applications quicker. It's
not without drawbacks, as have been pointed out, but it's manageable.

In practice, we don't do this anywhere (default value changes based on
import version) and we don't have language support for doing it. By
the time we get to instantiating a QQuickText element, we're past the
stage with import information.

So I would like to resolve it this way, but it's not feasible. And I
do not want to risk breaking existing applications. So I recommend
this change should wait until QtQuick 3.0.

>
> On 29 Jan 2015, at 23:24, Robin Burchell <robin+qt at viroteck.net> wrote:
>> Ideally, we could also provide tooling changes to help cover the
>> migration, by warning in QQuickTextItem::setText if HTML was
>> discovered and an explicit format had not been set, or perhaps in
>> other custom tooling aids.

This is something that we could add now, if you want to make AutoText
warn on use (something like: "Text.AutoText determines this is plain
text. Please set Text.PlainText as Text.AutoText may be removed in
QtQuick 3.0"). The details of the message and its performance impact
would be up for a separate discussion, but it helps guide users
without breaking any existing applications.

>> Seperately, we may want to look at a restriction on the loading of
>> remote resources in Text. I can understand allowing remote URIs in
>> Image, but Text seems like an unexpected behavior to me.
>
> If we do that, there needs to be a way to override the restriction, maybe by adding a property to control whether loading of anything outside the QML is allowed.  It would IMO be OK to have this property false by default, since the majority of use cases don’t need it.

Or we can add the property now, but default it to true (no behavior
break). Then we can change the default to false next major version,
which I agree seems like a more sensible default.

Restricting remote URIs in RichText and StyledText is my biggest
concern about malicious user generated content in rich text (it could
force a request for an arbitrary external resource). So disabling them
and using StyledText would be the best defaults I think. Shame we have
to wait.

> I can imagine that loading remote resources is a useful feature which some apps are relying on.  In fact, a single Text element is practically a web browser already, for certain limited purposes.  It's kindof cool to forego the need for a real web engine if you need only to display lightweight mid-90’s HTML.

Which is really useful while the WebView is in flux or unavailable.
Before there was a WebView, we used Text to display HTML all the time.
By the time we had a choice we were already used to it. But for tables
and certain text/image layouts, HTML is still easier to use than QML
(just try inline images, even now).

I'm optimistic that by QtQuick 3.0 QML will be preferred for most
mid-90's-HTML style content and there will be a mature and efficient
WebView available as well, which will decrease use of the rich text
features.

> I also think we should add a source URL property like Image has.  It’s unfortunate to need to rely on ugly hacks like this one http://rschroll.github.io/beru/2013/08/12/opening-a-file-in-qml.html just to be able to read a file.  And I/O should be more agnostic about local and remote resources, as long as the fact that you are doing I/O is explicit rather than unintended.
>
> Sometimes you want network access to be really easy.  Other times you want to avoid security problems that come from unintentional network or filesystem access.  So we need to make it easy to go either direction, and enforce it consistently.

On this point, I'm hoping that we can make QML more flexible.
Depending on how your configure your QQmlEngine, it could be as locked
down as HTML or as open as native C. Which I currently imagine to be
implemented mainly by import restrictions and easy local file I/O
would go in a separate QtQml.* import (like how creating new windows
goes in a separate QtQuick.Window import). That's the goal, and makes
it easy in both directions, but it does mean local I/O should be
handled differently in order to be consistent down the line. Until
then we need to maintain the current behavior where a custom
QNetworkAccessManager can intelligently deny most requests, routing
through QNAM is why I/O is remote focused right now.

--
Alan Alpert