Fri 24 Mar 2017 06:29:37 AM UTC, original submission:
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
|