SyncValidation loop when using min-height

[turdparty]

Bug

I'm using haxeui-core & haxeui-openfl to run a html5 webapp and have a couple of xmls containing something like:

<vbox style="min-height:50px;">

I recently upgraded from versions 1.1.3 to 1.2.3. It used to work fine under 1.1.3. Under version 1.2.3, when I run the app it hangs/reports a syncValidation loop. I spent some time to nail it down, no funny resize behavior etc. It turns out if I remove the min-height properties everywhere it works fine. Keeping the min-height and switching back to 1.1.3 also works.

So it seems somewhere internally the min-height is causing a loop. There could be an issue with top-down vs bottom-up layout.

Steps to Reproduce (for bugs)

Just add some style="min-height:50px;" to the layout. haxeui-core & haxeui-openfl openfl test html5

[ianharrigan]

hmmm, there were some recently changes there - do you have a simplified example layout to play with?

[turdparty]

It turned out to be a combination of 2 things, so it took me a bit longer. It's a combination of percentWidth/Height, and min-height that causes the bug to trigger. Removing either will circumvent the bug.

I've added an example project below. As you can see I set the percentWidth & Height to 50 programmatically. This is because by default the haxeui "window" seems to be twice as big as it should be. I've been doing this for a while.. can't remember. Just haven't had the time to complain ;) But this seems to be another issue.

Anyway, if you combine that with the min-height property somewhere in the xml it causes the syncvalidation loop.

vest.zip

[ianharrigan]

Ok, ill check it out shortly (sorry of the delay, been on holiday :) )

[turdparty]

I ran into another weird syncvalidation loop issue. I haven't pinpointed the cause but I think it might be related to either padding or the scrollview showing or not showing the scrollbars when resizing the window.

I created an example project which shows the issue when run using openfl test html5. Start it in a smaller browser window, it will work fine, then maximize the window and the syncvalidation loop occurs.

You can prevent the loop by either removing the padding in loadview.xml, or by commenting the line in the Main.hx where the padding of the scrollview contents is set to 0. I would love for these syncvalidation issues to be resolved.

(The 50% height and width in the xml is to deal with the retina autoscaling bug, so you may have to change those to 100%)

On a side note, is there an easy way to hide the scrollbars of a scrollview so that they never show regardless of the contents?

test.zip

[ianharrigan]

Hey,

Thanks for the test app, ill check it out when i get a moment :)

On a side note, is there an easy way to hide the scrollbars of a scrollview so that they never show regardless of the contents?

Sure, you can style individual parts of the scrollview (including scrollbars) - in fact, you can do this with any part of any HaxeUI

heres some scrolling examples: http://haxeui.org/builder/?kxrmfw

(im pasting the source here for completeness in case the builder loses it for some reason)

<vbox style="padding: 5px;">
    <style>
        .scrollview-contents {
            padding: 0px;
        }

        /* HIDE UP / DOWN BUTTONS */
        #scrollview2 .horizontal-scroll .inc,
        #scrollview2 .horizontal-scroll .deinc,
        #scrollview2 .vertical-scroll .inc,
        #scrollview2 .vertical-scroll .deinc {
            display: none;
        }

        /* HIDE UP / DOWN BUTTONS AND ONLY SHOW WHEN SCROLLING */
        #scrollview3 .horizontal-scroll .inc,
        #scrollview3 .horizontal-scroll .deinc,
        #scrollview3 .vertical-scroll .inc,
        #scrollview3 .vertical-scroll .deinc {
            display: none;
        }

        #scrollview3 {
            mode: mobile;
        }

        /* HIDE UP / DOWN BUTTONS AND ONLY SHOW WHEN SCROLLING AND NICER SCROLLS */
        #scrollview4 .horizontal-scroll .inc,
        #scrollview4 .horizontal-scroll .deinc,
        #scrollview4 .vertical-scroll .inc,
        #scrollview4 .vertical-scroll .deinc {
            display: none;
        }

        #scrollview4 .horizontal-scroll {
            height: 9px;
            padding: 2px;
            background-color: none;
        }

        #scrollview4 .horizontal-scroll .thumb {
            height: 5px;
            background-opacity: .5;
            border-radius: 4px;
        }

        #scrollview4 .vertical-scroll {
            width: 9px;
            padding: 2px;
            background-color: none;
        }

        #scrollview4 .vertical-scroll .thumb {
            width: 5px;
            background-opacity: .5;
            border-radius: 4px;
        }

        #scrollview4 {
            mode: mobile;
        }

        /* NEVER SHOW SCROLLS */
        #scrollview5 .vertical-scroll,
        #scrollview5 .horizontal-scroll, {
            display: none;
        }
    </style>    
    <grid>
        <scrollview id="scrollview1" width="200" height="200">
            <box width="400" height="400" style="background-color: #FFCCCC;padding: 5px;">
                <label text="Normal" />
            </box>    
        </scrollview>    

        <scrollview id="scrollview2" width="200" height="200">
            <box width="400" height="400" style="background-color: #CCFFCC;padding: 5px;">
                <label text="No up / down buttons" />
            </box>
        </scrollview>    

        <scrollview id="scrollview3" width="200" height="200">
            <box width="400" height="400" style="background-color: #CCCCFF;padding: 5px;">
                <label text="Mobile mode" />
            </box>
        </scrollview>    

        <scrollview id="scrollview4" width="200" height="200">
            <box width="400" height="400" style="background-color: #CCFFFF;padding: 5px;">
                <label text="Mobile mode + nicer style" />
            </box>
        </scrollview>    

        <scrollview id="scrollview5" width="200" height="200">
            <box width="400" height="400" style="background-color: #FFFFCC;padding: 5px;">
                <label text="Never show scrollbars" />
            </box>
        </scrollview>    
    </grid>    
</vbox>

[turdparty]

Thank you for the example. It looks good in the builder. Unfortunately it does not seem to work in the test case I made. I was sort of hoping to work around the issue by not having visible scrollbars.

I did modify the test case a little and can confirm the syncvalidation loop doesn't seem related to the padding. It does seem very much related to the scrollview switching between having to create scrollbars or not, depending on the size of the contents to the size of the scrollview when resizing the browser window.

I'm working on a macbook with 2560 × 1600 retina resolution. So I've now set Toolkit.autoscale=false and Toolkit.scale=1, and set the xml ui to 100% instead of 50%. I've also removed the padding modifications. That might help with consistency.

Now if I set my browser window to 1150x640 and run openfl test html5, all the items in the scrollview are shown without the need for a scrollbar. Then when I decrease the window width to where the scrollview can no longer show all the items without the need for a scrollbar, the syncvalidation error occurs.

And the opposite is also true, if I set my browser window to 1200x1300 and run the test case, there is a horizontal scroll bar visible. Then when I increase the window width to where the scrollview is able to show all the items, the syncvalidation error occurs.

Also, for some browser window sizes the syncvalidation error occurs at the start, causing the app to show nothing at all. In my case this happens at 900x650 for instance, where the scrollbar is needed.

This seems like a pretty big issue to me. If you know of a quick workaround, I'd be very happy :)

I'll attach the modified test project. test3.zip

p.s. Removing the scaleMode="fitheight" attributes from the images in the xml circumvents the issue. I tried manually setting the width of the images to their height in UIEvent.RESIZE of the hbox parent but that just causes the same syncvalidation issue again when resizing the scrollview in the same way as described above.

[ianharrigan]

Hmmm, so yeah, thats weird the scrollbars didnt disappear, ill check that out. But it seems that the deeper issue is the syncval loop, so ill also look at that.

Thanks again for the test app - i havent run it yet, but im sure it will make getting to the bottom of this that much simpler.

Cheers, Ian

[ianharrigan]

btw, just a thought, but what version of haxeui are you using? I think the "display: none" was added recently so if "visible: false" works then you are likely on an older version of haxeui-core. If that is the case i would be interested to know if the issue still applies after an update (i suspect it will still be an issue)

EDIT: just noticed that this started happening between 1.1.3 and 1.2.3, so thats good to know (should make understanding it easier) - can you also try updating to latest git core and backend and seeing what happens?

[turdparty]

I am on 1.2.3 for haxeui-core and haxeui-openfl. "display: none" doesn't work either.

The test case works on the latest git versions! So it seems you can close this issue. How did you fix it? Can you remember the changelist number?

My full application is also no longer having the syncvalidation issue. Though I'm seeing some very weird things after moving to git, but I'll have to investigate further. I might be the cause.

[ianharrigan]

I didnt actively fix anything (but then again, i didnt actively try and break anything either). Glad its fixed, though i might jump back to 1.2.3 to see what the issue was if i have a few minutes.

Feel free to add any issues here (or as new issues, up to you) wrt to git version, i plan on making these official haxelib version very soon, so it would be nice to iron out any issues.

[turdparty]

Unfortunately it seems I was a bit premature.

The good news is that the workaround with never displaying the scrollbars works.

The bad news is that the syncvalidation issue still occurs when normally displaying scrollbars. You can reproduce this with the test example by removing the style node from the xml. Then run using openfl test html5 and increase the width of the browserwindow so that the scrollview no longer needs a horizontal scrollbar. That's when the syncvalidation issue occurs.

For me personally, using the workaround is fine. So I'm not sure about the priority.

Another thing I just noticed in the test example: Mouseinput for scrolling is detected differently depending on the window size. You can reproduce this by simply running the test case and making the browser window very small, so that it still needs to scroll the contents. Notice that you can't scroll the scrollview by clicking on the middle or upper part of the images and moving the mouse left or right. It will only work on the lower part of the images. As if there's an invisible scrollbar that you're clicking on. When you increase the browser window, and try scrolling, you'll notice it doesn't matter where you click on the image as usual.

[Sartoric]

Got a similar problem after upgrading to haxe 4.2.3 Compiling openfl -> neko (also html5 doesn't work, it just shows a blank page)

It seems to be somehow related to height="auto" property on my frame. If I remove it, it works as expected (at least on neko and html5)

attached some samples files

test.zip