[HTML5] TextField not fixed yet [SOLVED with Lime 5.4.0 & Openfl 6.1.0]

[GiG]

Hi,
my problems with TextFields are a very old story, and ofter wonder if I am the only one struggling with this hassle. Today I have tried a different approach, getting a predefined textfield from a SWF (and setting a custom text), as I am converting an old AS project that used a lot of textfields defined in the SWF.

As you can see the textfields keep being cut on the right, as if the width was calculated wrong when updating the text.
I tried changing alignment in the FLA but nothing changed.
This problems persists from when I started using Haxe in 2015, am I doing it wrong? I hoped that by importing a TF from a SWF the problem would have vanished, but it has simply been confirmed, it exists and it is not just me and my way of coding
I absolutely need a fix or a valid workaround, as the problem periodically shows up.

I am using webGL, latest libs.

[singmajesty]

Does -Dcanvas make a difference?

TextField is SUPER complicated, and text handling on HTML5 canvas (especially) is quite poor. However, work on TextField has been picking up recently

[GiG]

I have always used canvas, this is the first project that uses webGL: the problem looks exactly the same.

If I can I will try to compile the test projects for textfields with webGL to see if the errors are the same.

[player_03]

Does this happen with all fonts, or just one?

[GiG]

In this case I can test Helvetica only.
The problems I had in the past were with Jersey, Myriad Pro (Light Condensed / Condensed) etc.
With the new release of Openfl the problems seemed to have decreased consistently, but a few days ago my colleague updated the libs and 1-2 texts cut on the right appeared.
I am pretty sure that the problem is in the calculation of textfield width, it looks like autosize misses something.

— UPDATE: I tried to temporarily fix the problem by:
1 - updating text as usual
2 - disabling autosize (TextFieldAutoSize.NONE), otherwise width is locked
3 - increasing the tf.width by 15 pixels

At least one textfield (an easily reproducible one) that was previously wrong is now correct.

canvas/webgl, same behavior.

[GiG]

TEST 1: base code

tf.text = textString;

---

TEST 2: disable autosize

tf.text = textString;

trace("tf.width = " + tf.width);
tf.autoSize = TextFieldAutoSize.NONE;
tf.width += 15;

CORRECT!

---

TEST 3: remove trace

tf.text = textString;

//trace("tf.width = " + tf.width);
tf.autoSize = TextFieldAutoSize.NONE;
tf.width += 15;

SURPRISE!

---

TEST 4: remove trace, keep call to width getter

tf.text = textString;

tf.width;
tf.autoSize = TextFieldAutoSize.NONE;
tf.width += 15;

SAME AS TEST 2, CORRECT! width getter is doing something…

---

BONUS TEST 5: move width getter down

tf.text = textString;

tf.autoSize = TextFieldAutoSize.NONE;
tf.width += 15;
tf.width;

SAME AS TEST 3, WRONG. width getter doesn’t help

---

canvas/webgl, same behavior.

[singmajesty]

It sounds like updating the layout internally (multiple times) is possibly destructive

[MSGhero]

Can you post a full code example for any of those test cases, including the creation of the textfield and the addChild call?

They all seem to work fine for me. Either all of the text can be seen (autosize = left) or the width is being set to 115 (default 100 + additional 15).

[CikaRaki]

Yes a full example would be helpful. Normally the layout should be the same no matter how many times you call it for the same text and textfield settings

[GiG]

UPDATE:
the previous tests were made on Lime 5.3.0 & Openfl 6.0.1

I have now upgraded libs to Lime 5.4.0 & Openfl 6.1.0 and (at least) this problem with textfields has gone, fixed!

I will make further tests, as my code for textfields uses different workarounds: I will try to remove them and see if the result is correct as soon as I can.
In the meanwhile… thank you all for your hard work!