[TextInput] SegFault on resize when percentWidth modified

[Peekmo]

Hello,

I found a bug, that I don't understand at all.

On a TextInput, if I set a percentWidth (any value) with set_percentWidth() or by accessing the attribute directly, there's a segmentation fault when I'm resizing the window (sometimes, not always).

I found that in TextInputLayout, resizeChildren(), if I comment lines which sets the height of TextField, no more segfaults (but no more text too :p).

I don't understand, if you have an idea ;)

public override function resizeChildren():Void {
        super.resizeChildren();
        if (container.sprite.numChildren > 0) {
            var vscroll:VScroll = container.findChildAs(VScroll);

            var text:TextField = findTextField();
            if (text != null) {
                text.x = padding.left;
                if (text.multiline == true) {
                    text.y = padding.top;
                    text.height = usableHeight; // This line
                } else {
                    text.height = text.defaultTextFormat.size + 8; // This line
                    text.y = (container.height / 2) - (text.height / 2);
                }
                text.width = usableWidth;

                var placeholder:Text = container.findChild("placeholder");
                if (placeholder != null) {
                    placeholder.width = text.width;
                    placeholder.height = text.height; // This line
                }
            }
        }
    }

[ianharrigan]

Hmmm, that is strange. Leave it with me and ill see if can reproduce. Im assuming this is the cpp/neko targets? Flash is fine?

[Peekmo]

I only tried cpp & neko yes. I can't test flash on my computer ^^"

[ianharrigan]

Ok,

Ill take a look (hopefully later this evening). Is there any chance you could post a minimal example (code or xml) so im know what im trying to reproduce? I have a feeling its going to be this line only:

text.height = text.defaultTextFormat.size + 8;

But ill need to confirm that when i get a moment.

Cheers, Ian

[Peekmo]

I will post an example this evening.

In fact, it's only this line if there's no placeholder, but if I add a placeholder to the input, the following line is problematic too:

placeholder.height = text.height; 

I think that the problem is "text.height" (but very strange..)

[Peekmo]

This is a piece of code that breaks :

package;

import haxe.ui.toolkit.controls.TextInput;
import haxe.ui.toolkit.containers.VBox;
import haxe.ui.toolkit.core.Toolkit;
import haxe.ui.toolkit.core.Root;
import views.Home;

class Main {
    public static function main()
    {
        Toolkit.init();
        Toolkit.openFullscreen(function(root:Root) {
            var vbox:VBox = new VBox();
            vbox.percentWidth= 100;
            var input:TextInput = new TextInput();
            input.percentWidth = 90;
            vbox.addChild(input);

            root.addChild(vbox);
        });

    }
}

It seems that it's only occurs when the container has a percentWidth too (not sure, but when I'm setting a fixed width, I don't get a seg fault, perhaps not enough tries (because it only breaks sometimes)).

Regards, Peekmo

[ianharrigan]

Ok,

Fantastic... Ill give it a run later and see what happens... I imagine that the reason it only happens with percent widths is because thats the only way to be changing the size values constantly. One more quick question: what version of haxeui are you on? Does it happen on the latest also?

[Peekmo]

It was on 1.6.10, I just tried on 1.6.12, it's the same thing.

[ianharrigan]

Ok, cool... thanks! Nothing much has changed since 1.6.10 that would have helped but thanks for testing it out again! Ill let you know.

Cheers, Ian

[ianharrigan]

Hmmm, well, ive been resizing the width of a windows release build of your code and so far nothing... :/

All seems to work fine. How long does it normally take to die? Any possibility of tracing some numbers out, or someway of finding out whats happening? Are you using openfl-next? Is there anything special in your application.xml?

When you resize the window, does it resize "live"? By which i mean, on my system if i make the window small and then make it larger again the "new" area remains black (and the text field the same size) until release the mouse button. Maybe on your system that is doing something in real time and that is breaking it? Clutching at straws... i know! :)

Cheers, Ian

[Peekmo]

It takes between 1 & 10 seconds, and yes, it resizes "live". Perhaps that's just a bug on my linux, the strange thing is that with buttons, no problems.

Perhaps nothing, just depends on the system. Sorry ;)

[ianharrigan]

No no, its not sorry... not at all... if it happens on one system it could (probably will) happen on another. Ill see if i can get "live" resizing working on my machine somehow... if you trace out values at the offending lines (ie, the ones you commented out to fix it) then what type of values do you get?

[ianharrigan]

PS: as a side note, i would like live resizing on my system anyway, or at least be able to tell openfl how to...

[Peekmo]

Hello, I added this traces

trace('before ' + text.height);
trace('text ' + text);
trace('defaultTextFormat ' + (text.defaultTextFormat));

text.height = text.defaultTextFormat.size + 8;

trace('after ' + text.height);

I've got this trace when it works

TextInput.hx:466: before 38
TextInput.hx:467: text TextField 6
TextInput.hx:468: defaultTextFormat { bold => false, font => Oxygen Regular, color => 2236962, size => 14, bullet => false, leftMargin => 0, tabStops => null, letterSpacing => 0, url => , italic => false, target => , underline => false, leading => 0, indent => 0, align => left, rightMargin => 0, kerning => false, blockIndent => 0 }
TextInput.hx:470: after 22

When it breaks, I've got only those ones

TextInput.hx:466: before 38
TextInput.hx:467: text TextField 6
Segmentation fault

Note : It only happens when resizing left & right borders (not top & bottom)

Thank you for your help Regards, Peekmo

[ianharrigan]

Does this mean that text.defaultTextFormat or text.defaultTextFormat.size is null or NaN? Sorry to be a pain, but can you add a check? Make sure its not not null and if it isnt make sure that size isnt null and is a number? As you said, its really strange...

[Peekmo]

Nothing logical..

                    trace('before ' + text.height);
                    trace('text ' + text);

                    if (text.defaultTextFormat != null) {
                        trace('innnnn');
                        trace('defaultTextFormat ' + (text.defaultTextFormat));
                        text.height = text.defaultTextFormat.size + 8;
                    }

                    trace('after ' + text.height);
                    text.y = (container.height / 2) - (text.height / 2);

gives..

TextInput.hx:466: before 38
TextInput.hx:467: text TextField 6
Segmentation fault

So .. the condition caused the segfault too. I think that my system is completly broken.