While I was inspecting a special-character issue in Gnash's ExternalInterface implementation, I got curious of how well Gnash handle ExternalInterface string data outside US-ASCII code points.

So, I wrote a dummy Flash-calls-JavaScript ExternalInterface test that tries to pass string with Thai characters as call's parameter for JavaScript to display; attached as `flash2js-thaiarg.html` in `jsflash-thaistring.zip`.

This test gives correct output when run with Flash Player: the string is passed to JavaScript and is correctly displayed on HTML page.

However, when using Gnash, once the HTML is loaded and the SWF file is run...

• There would be no output on the page.
• The browser seems to respond slowly.
• XUL `plugin-container` process would constantly consume 100% of CPU.
• Once ~10 sec is passed, a message "ERROR: Host container communication timed out" would appear on the console.
• Things will continue like this until I tried to open a new tab in browser.
• Once the browser responds, the browser would say that libgnashplugin "crashed".
• Once the "crash" message appeared, browser's response speed (and CPU usage) would come back to normal.

Despite what browser said, there's no core file dumped. Attaching GDB to a busy `plugin-container` process revealed that it didn't exactly "crashed", but rather "froze" (something like endless loop) until the browser killed it with SIGTERM.

According to Gnash-libgnashplugin communication log, the player side seemed to send Thai string parameter correctly (in UTF-8 encoding), but libgnashplugin sent back nothing (which explains "Host container communication timed out" message). So this is likely libgnashplugin's internal problem, especially how it parsed/converted/forwarded the NPVariant value.

Gnash: 0.8.11dev (git 8a11e60 8-Mar-2017) NPAPI
Flash Player: 11.2.202.491 (NPAPI)
Browser: Iceweasel 10.0.12esr-1 (debian)
Locale: th_TH (system encoding TIS-620)
System: Debian GNU/Linux 7.0 Wheezy i386