Backends now return error and response data, but public API has not changed.
This allows OpenFL to expose URLLoader.data on IOErrorEvent.IO_ERROR to match the behavior of Flash
Neko claims that the file passed to `fullPath()` must exist. Usually this isn't enforced, but apparently there are circumstances where it is.
c852db0004/libs/std/sys.c (L571)
I didn't take the time to pin down what those circumstances are. Instead I figured it was easiest to just rearrange some code to follow the rule.
I'd forgotten that they have their own list of dependencies. And sure, we could copy their list, but I worry that we'd forget to update it. This way is easier and takes less space.
The docs action only needs to look at Haxe code, so downloading the submodules just wastes 30-50 seconds. That's a lot of time for an action that clocks in at about 2 minutes.
The app's Timers should still continue when a window is hidden. Especially since an app could have multiple windows, with some being shown and some being hidden. If only one were hidden, the other shown windows would clearly behave in a broken manner because the one hidden window would cause all app timers, even those associated with other windows, to be paused.
Introduces new WINDOW_SHOW AND WINDOW_HIDE events from C++ to Haxe, and new onShow and onHide events on Haxe Window.
Followup to 0918ee2381
Previous attempt tried to use @:extern and @:enum for Haxe 3, but enum is fine for both, which is actually what we were using before. Keep @:extern for Haxe 3, but use enum for both
On SDL_APP_WILLENTERBACKGROUND and SDL_APP_DIDENTERFOREGROUND, inBackground was being toggled, but it was not toggled on SDL_WINDOWEVENT_SHOWN and SDL_WINDOWEVENT_HIDDEN. However, both pairs were dispatching WINDOW_DEACTIVATE and WINDOW_ACTIVATE from C++ to Haxe. When inBackground wasn't toggled, the UPDATE ApplicationEvent continued being dispatched from the C++, but the Haxe assumed that it wouldn't be. This meant that timers were still updated after WINDOW_DEACTIVATE for SDL_WINDOWEVENT_HIDDEN, but then they were still "advanced" as if paused on WINDOW_ACTIVATE for SDL_WINDOWEVENT_SHOWN. The next update time would be some time in the future, roughly equal to how long the Haxe thought the timers were paused. This could make it seem like the timers completed stopped updating, especially if they should have been paused for a long time. They would eventually continue, but they should have paused on WINDOW_DEACTIVATE and continued immediately on WINDOW_ACTIVATE.
