OpenFL 9.3.0 and Lime 8.1.0 Release

Hey, everyone!

Grab the latest feature releases for both OpenFL and Lime from Haxelib.

Today’s OpenFL update includes implementations of a number of new APIs from Flash and AIR, including the NativeWindow, NativeApplication, and SecureSocket classes, SampleDataEvent.SAMPLE_DATA for generating audio at runtime, FileReference.upload() on native targets to upload files to a server, and weak event listeners for JS and C++.

On the Lime side, the Window class gained some new properties, a new webassembly target replaced emscripten, a new -eval option allows running Lime tools without Neko, and a new -terser option allows using Terser to minify JS.

Check the changelogs below for even more new features and fixes.

Finally, I’m excited to say that we’ve released new updates for openfl on npm, starling-framework on npm, and actuate for the first time in several years. These versions of OpenFL and Starling allow developers to build projects using JavaScript — including languages that can compile to JavaScript, such as TypeScript, Haxe, and ActionScript 3.0 with Apache Royale). All samples for the npm versions (including JS-ES5, JS-ES6, TS, and AS3) have had their dependencies updated to use the latest versions of OpenFL, Starling, Webpack and relevant compilers. And our Yeoman generators for creating new projects, generator-openfl and generator-starling-framework have been updated with the latest dependencies too, along with swf-loader for using OpenFL library bundles with Webpack.



  • Added SampleDataEvent.SAMPLE_DATA to Sound class
  • Added class implementation
  • Added openfl.display.NativeWindow class implementation
  • Added partial openfl.desktop.NativeApplication implementation, including applicationID, exit(), Event.ACTIVATE, Event.DEACTIVATE, InvokeEvent.INVOKE for launch command line arguments, and properties to test if features are supported
  • Added openfl.display.Screen class implementation
  • Added class implementation for html5 target
  • Added upload() implementation to FileReference for sys targets
  • Added updateAfterEvent() to MouseEvent, KeyboardEvent, TouchEvent, and TimerEvent
  • Added separator and lineEncoding properties to File class
  • Added localPort, localAddress, remotePort, and remoteAddress to Socket class on sys targets
  • Added useWeakReference support to addEventListener() on html5 and cpp targets
  • Added support for referencing environment variables, like %PROGRAMFILES% in File path values on Windows
  • Added various enum, event, and error types to improve parity with types available in Adobe AIR
  • Added basic implementation of flash.text.StageText that falls back to TextField, similar to AIR desktop
  • Replaced String with EventType in FileListEvent, DatagramSocketEvent, and ServerSocketConnectEvent for better compile-time checks
  • Fixed Flash/AIR compatibility for DatagramSocketEvent, and ServerSocketConnectEvent classes
  • Fixed wrong type on size for FileReference and File to make it Float instead of Int (Some code may need to use after this change)
  • Fixed missing controlKey property on MouseEvent
  • Fixed missing Event.OPEN dispatch from download() on FileReference
  • Fixed corrupted binary files from download() on FileReference
  • Fixed cut and copy not being blocked by TextField when displayAsPassword is true
  • Fixed missing Event.OPEN, HTTPStatusEvent.HTTP_STATUS, HTTPStatusEvent.HTTP_RESPONSE_STATUS, and DataEvent.UPLOAD_COMPLETE events from upload() on FileReference
  • Fixed responseHeaders on URLLoader that should have defaulted to an empty array instead of null
  • Fixed HTTPStatusEvent.HTTP_STATUS on URLLoader, which should not have included responseURL and responseHeaders
  • Fixed missing HTTPStatusEvent.HTTP_RESPONSE_STATUS on URLLoader, which is where responseURL and responseHeaders should have been
  • Fixed runtime exception when using hardware-only texture with beginBitmapFill() by drawing black rectangle instead
  • Fixed BackgroundWorker deprecation warning when using File and FileStream after ThreadPool is introduced in Lime
  • Fixed events being dispatched from wrong thread when using asynchronous File APIs
  • Fixed dragging to scroll in TextField when scaled, by switching to getBounds()
  • Fixed empty data value on URLLoader when dispatching IOErrorEvent.IO_ERROR and server returned a response
  • Fixed Vector.ofArray() on flash/air targets
  • Fixed wrong signature on Socket constructor, which should not have had default values
  • Fixed incorrect “Lime Application” window title when targeting Adobe AIR on desktop
  • Fixed missing cleanup code when closing windows and shutting down application that could lead to memory leaks
  • Fixed event listener issue in TextField by comparing stage values to avoid issues with multiple windows or null stage
  • Fixed typo in name of Context3DAlphaMaskShader class
  • Fixed FlashGraphics being included in other targets under some circumstances by adding #if flash conditional
  • Fixed openfl.globalization, Namespace, and QName issues in npm version
  • Fixed incorrect condition that caused issues in ShapeCache
  • Fixed Socket incorrectly dispatching Event.CONNECT for unconnected sockets on Windows
  • Fixed wrong caps/joints in line style returned by readGraphicsData()
  • Added openfl_hack_fix_chrome_text define to workaround a bug in Chrome that garbles text
  • Added openfl_disable_text_measurement_cache define to allow the TextField shape measurement cache to be optionally disabled


  • Added visible property to Window to allow it to be shown and hidden
  • Added opacity property to Window
  • Added minWidth, minHeight, maxWidth, maxHeight, setMinSize(), and setMaxSize() to Window
  • Added new onShow and onHide events to Window
  • Added support for include.hxp file in libraries, similar to include.xml
  • Added support for multiple file extension filters on FileDialog operations
  • Added -eval option to run Lime tools without Neko
  • Added -terser option to Lime tools for html5 builds to optionally use Terser minifier
  • Added -npx option to Lime tools to run minifiers, or Electron, using npx instead of the bundled versions
  • Updated the bundled version of Node.js to 18 LTS for the html5 target’s HTTP server
  • Exposed more information to project.xml, such as ${} and ${}
  • Updated the Android Gradle plugin
  • Disabled pointer tagging on Android
  • Fixed issues in emscripten target and renamed it to webassembly
  • Fixed unpopulated responseData on HTTPRequest when server returns error status code
  • Fixed Clipboard contents being empty when app starts up on Windows and macOS
  • Fixed Unicode string conversion for alert() method on Window on HashLink target
  • Fixed asset cache clearing when unloading asset library
  • Fixed incorrect timer pause and resume behavior when window goes into background and back to foreground
  • Fixed .app file extension for macOS when building Adobe AIR captive runtime bundle
  • Fixed incorrect “Lime Application” window title for Adobe AIR applications
  • Fixed null check when opening file with FileDialog
  • Fixed expired Adobe AIR debug certificate
  • Fixed Haxe 3 compatibility for enum abstracts
  • Fixed running native apps with current working directory that does not match the program directory
  • Fixed assets being incorrectly located from Sys.programPath() instead of System.applicationDirectory
  • Fixed timing on html5 target by using so that system clock changes don’t cause issues
  • Fixed parsing of JNI class names
  • Fixed cleanup when windows are closed and the Lime application exits
  • Removed the defunct Kha backend

After the update I’m occasionally getting a build error on AIR target:

Called from ? line 1
Called from CommandLineTools.hx line 1903
Called from CommandLineTools.hx line 22
Called from a C function
Called from CommandLineTools.hx line 125
Called from CommandLineTools.hx line 640
Called from lime/tools/PlatformTarget.hx line 98
Called from AIRPlatform.hx line 364
Called from /opt/hostedtoolcache/haxe/4.2.5/x64/std/neko/_std/sys/io/File.hx line 37
Called from /opt/hostedtoolcache/haxe/4.2.5/x64/std/neko/_std/sys/io/File.hx line 53
Uncaught exception - [file_open,Export/air/haxe/debug.hxml]

The curious part is that it doesn’t always happen, only about 1/3 of the times I build it. On the other ones, the app runs without problems.

Interesting. There have been no changes to the file AIRPlatform.hx since Lime 8.0.0 was released over a year ago, so I don’t really have any clues about what might be happening there.

Thanks for all your hard work @joshtynjala and team!


OMG it’s a lot of work. Thanks you!


@joshtynjala which NDK was used to build the .so files in lime 8.1.0 btw? :slight_smile:

The Android library is still built with r15c in 8.1.0. We’ll be upgrading in 8.2 to at least r21e.


Looks like there is some problem with the Android build.

When building Pirate Pig I’ve got the following (the path already has “\” replaced by “/” btw for lime setup android).

Probably the issue is in lime\8,1,0\templates\android\template\, ::ANDROID_NDK_ROOT_ESCAPED::

build file 'C:\Work\PiratePig\Export\android\bin\build.gradle': 48: Unexpected character: '\'' @ line 48, column 11.
                  ndkPath 'C\:/dev/Android/ndk/21.4.7075529'

@joshtynjala I could fix the android build issue by editing android templates as follows:

Line 49
there should be
was ‘>=’

Same goes to
Line 18

A typo? :slight_smile:

Not a typo. Android changed how you specify the NDK path around AGP version 4.0. Versions before that don’t support the ndkPath property in build.gradle, and instead require ndk.dir in So changing >= to < will make old versions of the plugin fail. You’d be better off commenting the line.

Interestingly, it seems ndkPath wasn’t introduced until AGP 4.1, so for 4.0 specifically it will fail. But Lime defaults to 7.3.1, so I wouldn’t think that was the issue.

I do have to wonder how it’s coming up with the string “C:/dev/Android/ndk/21.4.7075529”. ANDROID_NDK_ROOT_ESCAPED hasn’t changed since 2018, several versions back. Can you check .hxcpp_config.xml and/or lime setup android to make sure you didn’t type an extra slash?

Ah! So basically I just removed the ndkpath from build.gradle for my build (that is done with NDK over 4.0). But it worked.

I can confirm that I didn’t type an extra slash. In fact, C: is a correct escaped version of c: and I can observe the Android SDK (not NDK, ANDROID_SDK_ESCAPED) used earlier in the build log escaped like this: c:\dev\Android and it works fine. I’ll be able to send the full build log on Monday. Anyway, I tried different ways (including adding my own and could see my changes reflected in the build log, but c: was always there and was causing the error. I could change \ to /, but there is no way to replace : :slight_smile:

I could ake the build work replacing ANDROID_NDK_ROOT_ESCAPED by ENV_ANDROID_NDK_ROOT (with whatever slashes in the actual path from the android setup) in the templates as well, so for me the escaped path doesn’t work, but the raw path works fine here.

Lime 8.0.2 doesn’t have ndkPath property in the Android templates btw.

Does anybody still use NDK < 4.0 :thinking:?

Oh of course, what’s happening is that the escape code puts a backslash in front of any special character it finds, including colons. Can you revert your changes to build.gradle and try this fix instead? (You’ll need to run lime rebuild tools or compile with -eval.)

Yes, it fixed the issue, thanks!

Great! No idea why the mangled path wasn’t a problem before, but we should be able to get this fixed in the next patch.

Alternatively, we could try the recommended option of using ndkVersion. This could simplify the lime setup android process a bit, because you’d only need to type in the version number, not the full path. And then the Android SDK would be responsible for locating the exact folder.

Actually, this seems like something you could put in project.xml. Maybe you could set a default NDK path using lime setup android, but if you specified an NDK version in project.xml, it would use that instead.


I confirm that Android builds on Windows seem to have broken at some point between Lime 8.0 and Lime 8.1. If I switch back to Lime 8.0.2, I can build for Android on Windows, but I can’t with 8.1.0.

I locally tested the PRs from @player_03 (#1720 and #1721), and they both allowed me to successfully build for Android on Windows again.

1 Like

I’m leaning towards the second of those two pull requests. Don’t escape so many characters if they aren’t necessary.

Though before we do that, we should track down whoever added that character-escaping code and ask if there was a reason for it. Don’t want to accidentally break anything!

…So, funny story. That was me.

(Makes sense in retrospect. I might be the only Lime dev who regularly uses regexes.)

I don’t recall doing it, but after reviewing some documentation for .properties files, it’s clear I was trying to escape characters with special meanings in .properties files. Of the six characters in the regex, two indicate comments, three are used as delimiters, and backslash escapes characters. However, comments only work at the beginning of the line, and only the first delimiter on a line has any effect, so we never needed to escape those characters. And I guess .properties files ignore extraneous backslashes, so all was well at the time.


I’m trying to use this but it doesn’t seem to work : when calling load() on a FileReference instance because file is null/undefined

from FileReference.hx line 948 :
var file = __inputControl.files[0];

through debug I can see that after a successful call to <FileReferenceList>.browse(filterList) every FileReference in <FileReferenceList>.fileList has a zero-length __inputControl.files

Am I missing something or is it not working ? This is with OpenFL 9.3.1 and Lime 8.1.0, trying to load jpg and png files

edit : I can create a small repro case if needed

It appears that @Dimensionscape committed the initial implementation, so he might be the one to ask.

I made a few commits after that to fix compilation issues with various Haxe versions, though.

1 Like

Thanks, I remember working on this with him as well and proposing a PR but since it wasn’t merged I naively thought it was to make it work like it used to in Flash.

After reading the code from his commit I understand that FileReferences in <FileReferenceList>.fileList are already loaded after the files are selected, so you can use <FileReference>.data right away.

Calling <FileReference>.load() in that context will result in an error. Maybe the html5 code for <FileReference>.load should check if data is populated and just dispatch Event.COMPLETE if it is ?

I believe with Flash we still had to load each FileReference instance (my memory could be bad though !)

1 Like

There is anothere issue : FileReferenceList never dispatches Event.CANCEL when the user cancels the file dialog

I tried to fix it on my end by looking at how FileReference does it but no luck for me

edit : opened an issue about this on github