html5 bugfix: enable onResize.dispatch when project.xml window resizable=true

[jobf]

This is a bug fix for the following issue.

onResize event issue

Adding window element to project.xml prevents the Application.window.onResize event from triggering

e.g.

<window width="800" height="600" resizable="true" />

makes this line never hit

https://github.com/openfl/lime/blob/5634ad72d2d71f9e910f15a8652eaf15891d7ad7/src/lime/_internal/backend/html5/HTML5Window.hx#L1273

There is a small project here that can be used to reproduce the issue https://github.com/jobf/lime-html5window-resize-glitch

[jobf]

The following code snippet can be used as a workaround.

Add to your class which extends Application

#if html5
override function onWindowCreate() {
    @:privateAccess
    var html5Window:lime._internal.backend.html5.HTML5Window = window.__backend;
    @:privateAccess
    html5Window.resizeElement = true;
}
#end

[player-03]

Man, that class is messier than I realized.

My main concern is that updateSize() deliberately distinguishes between __resizable and stretch. There might be a good reason for that, even if it isn't documented.

[player-03]

Adding window element to project.xml prevents the Application.window.onResize event from triggering

Also, this isn't quite right. Adding the window element isn't what prevents it, setting the dimensions is what prevents it.

[jobf]

Adding window element to project.xml prevents the Application.window.onResize event from triggering

Also, this isn't quite right. Adding the window element isn't what prevents it, setting the dimensions is what prevents it.

That makes sense.

I've also noticed the behavior is inconsistent in hashlink. For example if the window size is set there you can still resize the window and the only way to prevent it is to set resizable="false", as the window is resizable by default in both cases.

I have not tested other targets but I think it's ergonomic to have resizable="true/false" as the setting that enables/disables it.

Perhaps this is a larger can of worms :sweat_smile:

[joshtynjala]

I've also noticed the behavior is inconsistent in hashlink. For example if the window size is set there you can still resize the window and the only way to prevent it is to set resizable="false", as the window is resizable by default in both cases.

HashLink is definitely behaving correctly. Setting width and height on the <window> element is intended to set the initial window size, and it should have no effect on whether the window may be resized by the user.

[jobf]

I'm closing this because it's not really a problem in the way I thought it was, although in general there is some mess there that would benefit from some attention.