We usually try to track as closely as possible the proprietary player as most SWF authors code using the proprietary player as a reference. Sometimes different versions of the proprietary player (PP for short) behave differently and that's why we setup an online repository of our actionscript.all tests to make it easier for different people on the net to report eventual weird behavior (failures) with their version of the player.

Unfortunately the online versions are not available at the moment, but you could produce them with "make online-tests" from under testsuite/actioncsript.all. I guess we'll want to publish them somewhere else and call users for testing.

When the platform makes a difference, we pick the Windows version as the reference one. As for the version, the most stable version should be considered.

Patch included for fixing `Infinity`/`-Infinity`/`NaN` parsing of ActionScript
callback return value, and precision loss of JavaScript function return value.
See patch #8942.

Relevant text output from `js2flash-rtypes.html` with patched Gnash:

PASSED: Flash callback integer_call should return a correct type
PASSED: Flash callback integer_call should return a correct value
PASSED: Flash callback float_call should return a correct type
PASSED: Flash callback float_call should return a correct value
PASSED: Flash callback infinite_call should return a correct type
PASSED: Flash callback infinite_call should return a correct value
PASSED: Flash callback neginfinite_call should return a correct type
PASSED: Flash callback neginfinite_call should return a correct value
PASSED: Flash callback nan_call should return a correct type
PASSED: Flash callback nan_call should return a correct value

You'd see that `Infinity` return value from `infinite_call(), `-Infinity` from
`neginfinite_call()`, and `NaN` from `nan_call()` are now passed correctly
from ActionScript callback to JavaScript.

Relevant trace output from `flash2js-rtypes.html` with patched Gnash:

82 TRACE: PASSED: JavaScript function integer_call should return a correct type
82 TRACE: PASSED: JavaScript function integer_call should return a correct value
82 TRACE: PASSED: JavaScript function float_call should return a correct type
82 TRACE: PASSED: JavaScript function float_call should return a correct value
83 TRACE: PASSED: JavaScript function infinite_call should return a correct type
83 TRACE: FAILED: JavaScript function infinite_call should return NaN
83 TRACE: PASSED: JavaScript function neginfinite_call should return a correct type
83 TRACE: FAILED: JavaScript function neginfinite_call should return NaN
83 TRACE: PASSED: JavaScript function nan_call should return a correct type
83 TRACE: PASSED: JavaScript function nan_call should return a correct value

You'd see that return value from `float_call()` JavaScript function is now
passed back to ActionScript correctly.

Gnash: 0.8.11dev (patched against git a72afa5 9-Mar-2016) NPAPI
Browser: Iceweasel 10.0.12 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

The problem on JavaScript-calls-Flash return value boils down to how
libgnashplugin parses `<number>` data from player side:

        } else if (tag == "<number>") {
            start = end;
            end = xml.find("</number>");
            std::string str = xml.substr(start, end-start);
            if (str.find(".") != std::string::npos) {
                double num = strtod(str.c_str(), nullptr);
                DOUBLE_TO_NPVARIANT(num, value);
            } else {
                int num = strtol(str.c_str(), nullptr, 0);
                INT32_TO_NPVARIANT(num, value);
            }

There are few problem with this:

• It fails when `Infinity`, `-Infinity`, or `NaN` is encountered, as the plugin would parse it as an integer (and results in zero value).
• It fails when the number is a whole number but is not in `int32_t` range, e.g. 4294967295.

As I understand, plugin's `ExternalInterface::parseXML()` is used only for
parsing player's answer from JavaScript call (both ExternalInterface and
built-in plugin functions), unconditionally parsing the number as `double`
shouldn't cause any problem, as it is same type as JavaScript's `Number`.

Gnash: 0.8.11dev (git c12c3cf 22-Feb-2016)
System: Debian GNU/Linux 7.0 Wheezy i386

Original `js2flash-rtypes.html` test is attached as `js2flash-rtypes.zip` (file #36330).
Original `flash2js-rtypes.html` test is attached as `flash2js-rtypes.zip` (file #36331).
Both files were originally posted in bug #47004.