Hi again!
As a team, we have been focused recently on expanding our unit, integration and functional testing for OpenFL. This is not reflected in the changelog, but my hope is that we will be able to increase our test coverage and to make it easier to ensure that we’re properly guarded against regressions, while also easing the way for more contributors to improve OpenFL.
Our extra testing recently has helped us resolve a number of minor issues we discovered, and is already improving the quality of the release. 
OpenFL 8.8.0 (01/07/2019)
- Added
ByteArray.defaultEndianproperty - Updated canvas
TextFieldrenderer to use text baseline for more consistent rendering - Updated the types for
KeyboardEventon Flash to improve support forswitchcases - Improved
UncaughtErrorEventshandler to not run on debug by default - Initial support for mouse wheel support in
TextFieldscrolling - Disabled some incorrect HTML5 canvas renderer blend modes
- Fixed the behavior of
ByteArray.defaultObjectEncoding - Fixed a possible infinite loop when applying word wrap to narrow
TextFieldinstances - Fixed a regression in marking
scrollRectchanges as dirty - Fixed a regression in HTML5 DOM rendering when objects are removed from the stage
- Fixed dirty object calculation for
removeChildin some renderers - Fixed issues in SWF processing to improve NPM/Haxelib release compatibility
- Fixed
Loaderto dispatch an error ifLoader.loadBytesreturns a nullBitmapData - Fixed some issues with multi-format
TextFieldline breaking - Fixed some minor issues for users trying to use OpenFL with unsupported Haxe versions
- Fixed some issues with
Graphicsobjects being dirty when usingcacheAsBitmap - Fixed missing
Event.CONTEXT3D_CREATEevent ifrequestContext3Dis called again - Fixed support for using AMF0/AMF3 object formats in NPM
ByteArray - Fixed the behavior of
MovieClipwithbuttonModebut withenabledfalse - Fixed some issues when setting the
CubeTexturesampler state - Fixed support for disabling the context menu on browsers that show on mouse down
- Fixed unnecessary Lime version warning when running
openfl create - Fixed a case where
Stage3Dcould render when the context had not been cleared - Fixed
Sound.getLengthfor sounds streamed from OGG Vorbis audio files
ByteArray.defaultEndian
Some versions ago (in OpenFL 6, I believe), we changed our endianness behavior to match the host platform. This was done because it matches the behavior on all our targets – C++, Neko, HTML5 (and other experimental targets) – while breaking from the behavior of Flash Player. This helps improve our performance, and helps improve interoperability between OpenFL programs and native extensions or other native applications.
ByteArray has a defaultObjectEncoding property that can be used to distinguish between AMF0 or AMF3 object serialization formats in Flash Player. OpenFL includes support for both AMF0 and AMF3 objects (if you have <haxelib name="format" /> in the project) but also has support for HXSF (Haxe serialization) or JSON object formats. Each new ByteArray object that is created will set it’s objectEncoding value to match this default. On non-Flash targets, this is already different than Flash (HXSF) but this also provides to easily match Flash without setting the field on every ByteArray you create.
We decided to add a ByteArray.defaultEndian property. Although this is not a part of the Flash API specification (which is always BIG_ENDIAN for “network byte order”) introducing this, we felt, was an important part of making it more clear (and easier to control) that OpenFL does allow different default endian values, and that by default, this varies between Flash and other platforms, which match the host. With the exception of some server backends which use BIG_ENDIAN, 99% of devices use LITTLE_ENDIAN instead.
More Testing
We’ve been broken our old Haxelib unit tests into two separate test runners, “unit” and “integration”.
The OpenFL unit tests run without Lime and should be platform-agnostic. We’re currently using a custom version of munit with fixes for better async test support. This is also running currently on the terminal using the Neko target only.
Using a development version of OpenFL, use hxp unit-test to run all of the tests, or hxp unit-test --filter=openfl.display (or another value) to filter the tests to run fewer at once.
We also use our unit tests in the integration test suite. The integration test is designed to include Lime, and to be tested in multiple environments. We can run both Flash and HTML5 side-by-side using the standard munit web runner, or test C++, Neko, AIR and Electron from the terminal.
In this environment, we can expand testing to features which address how multiple classes interrelate to each other, and test features which require a real window and real application to be running, but can still be tested in a headless fashion.
Using a development version of OpenFL, use hxp integration-test web to run Flash and HTML5 side-by-side in a browser window, or hxp integration-test neko (or another target) to run the suite on another desktop platform. We haven’t been testing against mobile platforms using these tests, but that may be possible as well.
Lastly, the functional tests for OpenFL are an OpenFL application which is set up to host a number of tests that must be verified manually. In the future, we’ll want to drive as much testing as possible back down into our unit or our integration testing, but the functional tests are helping fill in an important gap in our ability to validate OpenFL’s support of each feature – the reality that some features are hard to test automatically, and to help broaden the amount of code we test before each new release.
We’d appreciate any help in expanding our tests!
Setup for running tests requires 1.) OpenFL, 2.) munit (https://github.com/openfl/munit) and 3.) HXP
Other Changes
There are many things that could be said about this release, so please feel free and ask if there is anything else you are curious about!
Thanks to all our contributors and Patreon supporters.
Looking forward to a bright 2019! 