Long text on iPhone

[Ana_Almeida]

Hello guys,

It was called to my attention an issue with iPhone X where large texts were shown as a black box:

This only happens on iPhone X. I tried to investigate a little further, but I can’t find anything that justifies this behavior, such as character limitations.

So, out of curiosity, I tried to understand what that black box is, when selecting that said black box, the text behind it shown:

It shows the actual text I was hoping to see instead of the black box.

This is a plain text field:

<ScrollView>
	<StackPanel>
		...
		 -- Component with StackPanel --
		...
	</StackPanel>	
</ScrollView>

The StackPanel component has:

<Text Value="{description}" TextWrapping="Wrap" Alignment="Left" />

This also happens when the field is a TextView:

<ScrollView>
	<StackPanel>
		...
		<TextView Value="{description}" TextWrapping="Wrap" Margin="0,0,0,0">
		...
	</StackPanel>	
</ScrollView>

Also, as you might notice when I select the text, it kinda have a strange behavior, the Text and the TextView go all over the place.

So, I’ve done the same test on iPhone 6. It doesn’t show me the black box, but the Text and TextView have the same behaviour.

I have some questions about this.

• Does anyone ever noticed the black box in iPhone X when the fields have long text.
• Does anyone know why the Text and Text View has this behavior with long texts?
• Can all of these be fuse related?

I’m using:

• Fuse version 1.7.1 (build 15473)
• iPhone 6 iOS version 11.2.6
• iPhone X iOS version 11.2.5

Thanks in advance.

[Uldis]

Hi Ana,

this is a known limitation, and one that affects not only iPhone X, but practically all mobile devices. It’s only a question of how much text you need to trigger this issue on a particular device.

Please see this forum post for an explanation why that is, and what causes it (hint: it’s not just the text length). There’s of course a workaround, too.

[Ana_Almeida]

Hello Uldis,

I saw that post too, but I was expecting that, with that amount of text, if it happens on iPhone X it also would happen on iPhone 6. Actually I tested it, and to see the black box on iPhone 6 the text I need is 4 ou 5 times more than the one I use in iPhone X. Anyway, the workaround doesn’t work for me, because that field has only one Text component, so I have to show the text all as one.

This answers the question about limitations, but what about the text overlaying everything else when selected, even if it’s not an input field? It also happens on Android but just with the input field (TextView), not with the plain text (I believe this is because, in Android you cannot select text and on iOS you can).

[Uldis]

I saw that post too, but I was expecting that, with that amount of text, if it happens on iPhone X it also would happen on iPhone 6. Actually I tested it, and to see the black box on iPhone 6 the text I need is 4 ou 5 times more than the one I use in iPhone X.

As it was explained in that forum post I linked, this depends on the device. Apparently, iPhone X implies some stricter limits on memory use than iPhone 6.

Anyway, the workaround doesn’t work for me, because that field has only one Text component, so I have to show the text all as one.

Of course it could work for you. If you have the text content in JavaScript, you could totally split it into multiple parts, and then stitch it back together in UX by using Each inside of a WrapPanel or StackPanel.

This answers the question about limitations, but what about the text overlaying everything else when selected, even if it’s not an input field? It also happens on Android but just with the input field (TextView), not with the plain text (I believe this is because, in Android you cannot select text and on iOS you can).

When you “select text” (whatever that means), or when it’s shown in a text editor, what actually happens is that a native text control is shown. Native text controls don’t imply the same limits that components rendered with GL do. The problem is rendering text with GL.

And that ^ made me think. What if you wrap the Text in a NativeViewHost, does that help?

[Ana_Almeida]

Of course it could work for you. If you have the text content in JavaScript, you could totally split it into multiple parts, and then stitch it back together in UX by using Each inside of a WrapPanel or StackPanel.

The StackPanel or the Wrapanel might work when I have a read only text, but when I want to edit said text I want to edit it as a whole, not some parts of it.

When you “select text” (whatever that means), or when it’s shown in a text editor, what actually happens is that a native text control is shown. Native text controls don’t imply the same limits that components rendered with GL do. The problem is rendering text with GL.

And that ^ made me think. What if you wrap the Text in a NativeViewHost, does that help?

What I mean with “select text” is when you click on it for editing and the keyboard appears.
If I wrap the TextView in a NativeViewHost this happens:

And the text is not even selected for edition.

I’ve also tried to wrap the ScrollViewalso in NativeViewHost but:

So unfortunately the NativeViewHost doesn’t work.

[Uldis]

I guess it would be best if you could provide a complete, minimal reproduction that we could test on our end. Perhaps we could even come up with a solution.

[Ana_Almeida]

Uldis,

Can you please give me the link to upload the minimal reproduction?

Thanks

[Arturs]

Hey Ana!

Here is the link to upload project - https://www.dropbox.com/request/ZgndLtJQm5eGzG9cicGK

[Ana_Almeida]

Thanks!

I’ve uploaded “TextTest.zip”.

Basically there are two pages, the main page with a long text and the second page that is an overlay.

• Without using NativeViewHost the text overlaps the other components.
• With NativeViewHost surrounding the ScrollView, I can’t edit all the text because I can’t see the bottom of it, and when opening the second page it shows me the long text along with the content of this page.
• With NativeViewHost in the TextView, it overlaps the other components and when opening the second page it shows me the long text along with the content of this page.

[iDalhaug]

Hi, I’m having the same issue as below…

[Arturs]

Hey!

I have created issue ticket for long texts.