Sat 27 Feb 2016 10:25:57 AM UTC, comment #14:
ExternalInterface issues related to `Number` type are now tracked separately as bug #47280.
|
Sat 20 Feb 2016 06:53:06 AM UTC, comment #13:
Patch included for fixing `null` return value and incorrect error messages;
see patch #8914.
This is text output of `js2flash-errorstring.html` on browser with patched Gnash:
Debug log (verbosity 1 + action error) from the run:
You'd see that there are no "ERROR: Couldn't process ExternalInterface Call..."
message appearing after `error_call()` and `securityerror_call()` callback
invocation anymore.
This is text output of `js2flash-rtypes.html` on browser with patched Gnash:
You'd see that return value from `null_call()` ExternalInterface callback
is now correctly seen from JavaScript as `null`.
Other failures regarding numeric return values are remaining
to be investigated, possibly as a separate report.
Gnash: 0.8.11dev (patched against git 051aa9c 15-Feb-2016) NPAPI
Browser: Iceweasel 10.0.12 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Sat 20 Feb 2016 03:52:05 AM UTC, comment #12:
This is text output from `js2flash-rtypes.html` on browser with current Gnash:
You'd see that libgnashplugin didn't crash at integer Number access anymore
(the remaining crash likely to be bug #37223). But there's one unexpected
wrong result; ExternalInterface callback `null_call` is now returning
"Error" string instead of `null`.
According to player-to-container communication dump which shown
`<string>Error</string>` return value from `null_call`, this is likely due to
leftover in-band error flag generation in Gnash (player); narrowed down to
code in `movie_root::callExternalCallback()` around line 1964:
This flags legitimate `null` return value from ActionScript callback as
an error, and send it to libgnashplugin as in-band "Error" string indicator.
(It doesn't turn back to `null` before reaching JavaScript as in-band
ExternalInterface error signalling is now dropped from libgnashplugin)
Output, logs, backtraces, and screenshots from testing
`js2flash-errorstring.html`, `flash2js-errorstring.html`, `js2flash-rtypes`,
and `flash2js-rtypes` are attached as `jsflash-errorstring-rtypes_roundup.051aa9c.zip`.
Gnash: 0.8.11dev (git 051aa9c 15-Feb-2016) NPAPI
Browser: Iceweasel 10.0.12 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
(file #36405)
|
Sat 20 Feb 2016 03:43:20 AM UTC, comment #11:
This is text output from `js2flash-errorstring.html` on browser with current Gnash:
Gnash's debug output (verbosity 1) from the run:
You'd see that the value returned to JavaScript is now correct, but there are
some odd "ERROR: Couldn't process ExternalInterface Call..." messages
appearing in the debug output.
This could be narrowed down to Gnash (player)'s ExternalInterface callback
handling code function `movie_root::processInvoke()` in `libcore/movie_root.cpp` around line 1683:
This flags legitimate "Error" and "SecurityError" string return value from
callback as error and returned `false` from the `movie_root::processInvoke()`
function, triggering error message.
This doesn't affect return value seen from JavaScript as `movie_root::callExternalCallback()` already sent it to host container.
Gnash: 0.8.11dev (git 051aa9c 15-Feb-2016) NPAPI
Browser: Iceweasel 10.0.12 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Mon 15 Feb 2016 10:37:11 AM UTC, comment #10:
Ready for test as patch #8909 have been applied
|
Sun 14 Feb 2016 11:20:39 AM UTC, comment #9:
I have written another set of test SWF/HTML file (compiles on MTASC),
which try to check on how Flash return value of various types from
ExternalInterface (in both direction).
JavaScript calls Flash direction: attached as `js2flash-rtypes.zip`.
Flash calls JavaScript direction: attached as `flash2js-rtypes.zip`.
Note: There seems to be some peculiarities regarding how Flash Player
deal with odd return values:
- `Infinity` and `-Infinity` value:
- In JavaScript-calls-Flash scenario, they were returned properly.
- In Flash-calls-JavaScript scenario, they were returned as NaN.
- Function-typed field in `Object` return value:
- In JavaScript-calls-Flash scenario, it refused to return the entire object; returned `null` instead.
- In Flash-calls-JavaScript scenario, the object itself is returned properly, though its function-typed fields were set to `null`.
Gnash: 0.8.11dev (git 435d3e9 6-Feb-2016) NPAPI
Flash Player: 11.2 r202 (11.2.202.491) NPAPI binary
Browser: Iceweasel 10.0.12 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
(file #36330, file #36331)
|
Mon 08 Feb 2016 09:54:29 AM UTC, comment #8:
Refer to task #5919 for the "protocol". I'm not sure it was ever fully specified, but that task would be the place to further discuss specifications, I'd think.
|
Sun 07 Feb 2016 12:43:23 PM UTC, comment #7:
Also, there seems to be some mismatching interpretation of `undefined` value
in Gnash's ExternalInterface implementation:
According to the table, the marshalling result of JavaScript and
ActionScript's `undefined` value is supposed to be "<void/>". As current
container-emulated tests are currently interpreting `undefined` as
"<undefined/>", not "<void/>" (following current Gnash player's output),
it would need to be adjusted when this bug is fixed.
Side note: `GetVariable()` plugin function and associated tests are not
affected by this discrepancy as the function does not return `undefined` value.
Gnash: 0.8.11dev (git 435d3e9 6-Feb-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
[1] http://git.savannah.gnu.org/cgit/gnash.git/tree/plugin/npapi/external.cpp?id=435d3e9aa7864883f6a2379fd318126113786475#n286
[2] http://git.savannah.gnu.org/cgit/gnash.git/tree/libcore/ExternalInterface.cpp?id=435d3e9aa7864883f6a2379fd318126113786475#n117
[3] http://git.savannah.gnu.org/cgit/gnash.git/tree/plugin/npapi/external.cpp?id=435d3e9aa7864883f6a2379fd318126113786475#n377
[4] http://git.savannah.gnu.org/cgit/gnash.git/tree/libcore/ExternalInterface.cpp?id=435d3e9aa7864883f6a2379fd318126113786475#n245
|
Sun 07 Feb 2016 12:25:52 PM UTC, comment #6:
Does Gnash's container-player XML communication protocol is implemented to
conform to some kind of specification?
I'd like to know if said spec has provision for exception handling in
remote procedure call, so I could implement them properly.
Alternatively, this could be implemented in a way that exception would
be turned into to `undefined` return value before sending it back to the
calling party. (Which is also a correct behavior as much as JavaScript
and ActionScript are concerned)
|
Sat 06 Feb 2016 12:19:43 PM UTC, comment #5:
This is another test SWF file (created with MTASC again) to show difference
on ExternalInterface exception handing between Flash player and Gnash,
but in Flash-calls-JavaScript direction.
Text output from running `flash2js-exception.html` under browser with Flash Player:
Player's trace output from the run:
You'd see that ActionScript side got `undefined` return value when JavaScript side thrown exception.
Text output from running `flash2js-exception.html` under browser with Gnash:
Gnash's debug output from the run:
You'd see that ActionScript side also got `undefined`, which is correct.
But container-player communication dump shown that libgnashplugin sent
following return value to Gnash player:
This is indistinguishable from ordinary string "Error" return value,
causing the problem that previously mentioned in comment 2.
Test SWF, source code, HTML container, build script, text output and logs
are attached as `flash2js-exception.zip`.
Gnash: 0.8.11dev (git 02ec1e6 3-Feb-2016)
Flash Player: 11.2 r202 (11.2.202.491) NPAPI binary
Browser: Iceweasel 10.0.12 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
(file #36267)
|
Sat 06 Feb 2016 12:01:28 PM UTC, comment #4:
I also made a test SWF file (using MTASC) to show difference on how Flash
and Gnash handle exception in ExternalInterface, in JavaScript-calls-Flash direction.
Text output from running `js2flash-exception.html` under browser with Flash Player:
Player's trace output from the run:
You'd see that JavaScript side got `undefined` return value when ActionScript side thrown exception.
Text output from running `js2flash-exception.html` under browser with Gnash:
Gnash's debug output from the run:
You'd see that JavaScript side got `null` when ActionScript side thrown
exception. According to container-player communication dump, Gnash (player)
correctly sent `<undefined/>` return value to libgnashplugin.
Test SWF, source code, HTML container, build script, text output and logs
are attached as `js2flash-exception.zip`.
Gnash: 0.8.11dev (git 02ec1e6 3-Feb-2016)
Flash Player: 11.2 r202 (11.2.202.491) NPAPI binary
Browser: Iceweasel 10.0.12 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
(file #36266)
|
Sat 06 Feb 2016 11:38:33 AM UTC, comment #3:
I have done some additional check on ExternalInterface's error condition
regarding exception, I found that with Flash Player plugin...
- When JavaScript called ActionScript function and it threw exception: JavaScript would just get `undefined` return value, without exception thrown.
- When ActionScript called JavaScript function and it threw exception: ActionScript would just get `undefined` return value, without exception thrown.
Flash Player: 11.2 r202 (11.2.202.491) NPAPI binary
Browser: Iceweasel 10.0.12
System: Debian GNU/Linux 7.0 Wheezy i386
|
Mon 01 Feb 2016 05:27:31 AM UTC, comment #2:
This issue is not limited to JavaScript-calls-Flash direction,
Flash-calls-JavaScript direction (`ExternalInterface.call()`) has the
similar problem.
I have made a test SWF (using libming's makeswf) that tries to call three
JavaScript functions which return string "Error", "SecurityError", and
"Hello!" to demonstrate this issue:
Trace output from running `flash2js-errorstring.html` under browser with Flash Player:
You'd see that string "Error", "SecurityError", and "Hello!" are passed back
to ActionScript correctly.
Log output from running `flash2js-errorstring.html` under browser with Gnash:
You'd see that "Error", and "SecurityError" string are passed back to
ActionScript as `undefined`, which is incorrect. Also, there are unknown
"VAL: " trace messages popped-up too.
According to container-player communication dump, each "<string>" return value
are correctly sent from libgnashplugin. So this side of the issue is likely
to be Gnash (player)'s fault.
Test SWF, HTML container, source code, build script, screenshots, logs, and
container-player communication dump are attached as `flash2js-errorstring.zip`.
Gnash: Gnash 0.8.11dev (git e705394 29-Jan-2016) NPAPI
Flash Player: 11.2 r202 (11.2.202.491) NPAPI binary
Browser: Iceweasel 10.0.12
System: Debian GNU/Linux 7.0 Wheezy i386
(file #36226)
|
Sun 31 Jan 2016 02:49:37 AM UTC, comment #1:
This problem could be narrowed down to `plugin/npapi/callbacks.cpp`, inside
function `remoteCallback()` around line 707:
This check doesn't seem appropriate, as:
- It fails when ActionScript's callback legitimately returned a string "Error" or "SecurityError"; demonstrated by test file.
- Bad things could happen if the return value is both not `null` and is not a String. (e.g. `NPObject`)
Second one is actually the reason I found this issue in the first place;
this string conversion code crashes when I tried to make
`ExternalInterface::parseXML()` return a full-blown `NPObject` derived
from JavaScript `Object` (a part of bug #32411's fix).
Gnash: Gnash 0.8.11dev (git e705394 29-Jan-2016) NPAPI
Browser: Iceweasel 10.0.12
System: Debian GNU/Linux 7.0 Wheezy i386
|
Fri 29 Jan 2016 08:05:26 AM UTC, original submission:
This is a spin-off from bug #37223 (ExternalInterface registration issue),
and bug #32411 (ExternalInterface Object data issue).
There is a weird problem in libgnashplugin's ExternalInterface callback
return value handling. I found that if a string "Error", or "SecurityError"
is returned from Flash-side callback, JavaScript would get `null` value
instead of the returned string. Other string values are passed correctly.
I have created simple SWF file (Flash 8) using libming's makeswf, which
registers a callback named `error_call` and `securityerror_call` and
`hello_call` which return string "Error", "SecurityError", and "Hello!"
to demonstrate this problem.
Text output from running `js2flash-errorstring.html` under browser with Flash Player:
You'd see that string "Error", "SecurityError", and "Hello!" are passed back
to JavaScript correctly.
Text output from running `js2flash-errorstring.html` under browser Gnash:
You'd see that "Error", and "SecurityError" string are passed back to
JavaScript as `null`, which is incorrect.
According to container-player communication dump, each "<string>" value
are correctly sent from Gnash's player side. So this is most likely to be
libgnashplugin's fault.
SWF file, source code, build script, HTML container, screenshots, text output
debug logs, and container-player communication dumps are attached as `js2flash-errorstring.html`.
Gnash: 0.8.11dev (git 62cfdfe 16-Jan-2016) NPAPI
Flash Player: 11.2 r202 (11.2.202.491) NPAPI binary
Browser: Iceweasel 10.0.12 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
|