Closed Bug 1193393 Opened 9 years ago Closed 9 years ago

Flash app returns ioerror when response is 200 on Firefox 40 with Asynchronous Plugin Initialization enabled


(Core Graveyard :: Plug-ins, defect)

40 Branch
Not set


(Not tracked)



(Reporter: venant.tang, Unassigned)




(Keywords: regression)


(2 files)

44.69 KB, image/png
528.42 KB, application/x-zip-compressed
Attached image Capture.PNG
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150806153638

Steps to reproduce:

1. Open Charles proxy or other http watcher to read the traffic

Actual results:

Request to WccWidget servlet call would be failed. You will see io error from the page. However, the charles proxy shows that the response is 200 ok. I tried the same flash player version 18 with older firefox 39 or other browsers. They are working fine.

Expected results:

It should work fine as it used to work fine with version 39 or below. It works fine with other browsers. This request starts breaking after the v40 released. This issue is very strange that it works with other http requests but not this one. 

Also, before the fix, do you have workaround so that our production can be patched for this?
Keywords: flashplayer
I'm able to load the Flash applet in FF40 with Flash, I don't see any error.

Which version of Flash player are you using?

In addition, is it reproducible with a fresh profile?
Flags: needinfo?(venant.tang)
I have the same problem with Firefox v.40 and Flash Firefox v39 works fine.

Somehow large http response bodys are cut off. I looked at it with wireshark and saw that at some point no more ACK is send by the receiving site. The TCP connection is sill open at that point.

I am able to reproduce this error with a fresh profile an also with Firefox 40.0.2 .
Welf, do you have a simple testcase to reproduce the issue?
COuld you give STR?
Flags: needinfo?(welf.warnecke)
Attached file
Hi Loic,

sorry I am not a flash developer and therefore can not give you a testcase. But I have compared the wireshark tcp stream with the response shown at the inbuild "firefox - networkanalyzer". All data is transfered via tcp, but it is cut off at firefox. Maybe my attachments can help.
Flags: needinfo?(welf.warnecke)
(In reply to Loic from comment #1)
> I'm able to load the Flash applet in FF40 with Flash, I don't see
> any error.
> Which version of Flash player are you using?
> In addition, is it reproducible with a fresh profile?
> firefox-profiles

The flash version is the latest It is still reproducible. The reason it works on my link is because we just found a hackaround. I put the content of the servlet in a file. Once IOError event comes, I would download that file instead for now. 

Now, I have another link below without my hackaround. You will see that the spinner would stay and the application couldn't load.
Flags: needinfo?(venant.tang)
venant, thanks for the link. Indeed, sometimes the Flash application never loads, sometimes it does.
And the response of is incomplete when it fails:

<?xml version="1.0" encoding="UTF-8"?><widgets><widget xmlns:ns2=""><code>player_slide</code><configUrl>/view/widgets/flash/library/slidearea/config.xml</configUrl><defaultHeight>508</defaultHeight><defaultWidth>640</defaultWidth><description>The Slides widget displays the PowerPoint slides that are presented to your audience during your webcast.  This widget also displays the polls, surveys and Flash video clips that are pushed to the slides section.</description><displaySequence>0</displaySequence><iconURL>/view/widgets/flash/library/slidearea/player_slide.png</iconURL><id>5</id><isPublished>Y</isPublished><name>Slides</name><version>v1.0</version><widgetUrl>/view/widgets/flash/library/slidearea/SlideAreaWidget.swf</widgetUrl></widget><widget xmlns:ns2=""><code>player_media</code><configUrl>/view/widgets/flash/library/mediaplayer/config.xml</configUrl><defaultHeight>0</defaultHeight><defaultWidth>320</defaultWidth><description>The Media Player widget plays the audio / video for your webcast (Flash stream).  For archived events, this widget allows attendees to pause, fast-forward or rewind the webcast presentation.</description><displaySequence>0</displaySequence><iconURL>/view/widgets/flash/library/mediaplayer/player_media.png</iconURL><id>6</id><isPublished>Y</isPublished><name>Media Player</name><version>v1.0</version><widgetUrl>/view/widgets/flash/library/mediaplay

I tested with FF40/41, it fails.
But with FF42/43, it works. So it's probably already fixed.

Could you download Aurora (42, see and Nightly (43, see to confirm it's fixed on your side.
Flags: needinfo?(venant.tang)
welf.warnecke, could you test too, please.
Flags: needinfo?(welf.warnecke)
Thanks for you guys work and following up on this bug so far. I appreciate that. 

Yes, v42 seems to be fixed. However, may I ask when will this fix be available for the current released version? After v40 released on Tuesday, we got reported with race condition bugs in flash player. This bug I reported here is only 1 of them. I found hackaround for most of them. However, there is one which other developers and I have spent 3 days on it and no hackaround couldn't be found. I will file another bug for it.
Flags: needinfo?(venant.tang)
See the calendar:
For FF42, it's 2015-11-03 (every 6 weeks).

Anyway you can file reports if you found some regression bugs in FF40. Some bugfixes can be backported sometimes.
EDIT: forget my previous messages, it's *NOT* fixed in Aurora/Nightly. The faulty feature is Asynchronous Plugin Initialization which enabled by default in 40/41 and disabled by default in 42/43. That's why it seemed to work.

If you set about:config > dom.ipc.plugins.asyncInit=false (restart FF to apply), it will work.
Component: Untriaged → Plug-ins
Ever confirmed: true
Flags: needinfo?(welf.warnecke)
Keywords: flashplayerregression
Product: Firefox → Core
Summary: flash ioerror when response is 200 → Flash app returns ioerror when response is 200 on Firefox 40 with Asynchronous Plugin Initialization enabled
Hello, I'd like to add our case to this problem.
Last week we started getting complaints from our Flash app users too (e.g. on, but you'd need to add the application on Facebook). All users with complaints have Firefox 40 and the same version of Flash on other browsers (i.e. does not cause a problem.

In our experience, this only happens with requests from Flash to our server that have big responses (>32 KB or in some cases, 16KB). Flash doesn't finish loading the response and an ioerror is returned. Looks like it is loading the response in chunks around 16KB but often stops short before the needed amount has been received (which can be any). Sometimes the response is fully loaded. This problem applies to responses seemingly at random.
It does not happen with requests from JS to our server that have the same filetype and are chunked and gzipped as well.

Example: (failed responses should have been around 180KB-300KB in size)

As far as I know, other social applications on Flash may have this problem too because the amount of data passed to the Flash app is large at times, for example, on initialization.

Also, I tried setting dom.ipc.plugins.asyncInit to false, the Flash application now hangs after completing the first request, an "Unresponsive plugin" message is shown a few times and then it crashes.
I'm also seeing this with a Flash app my company develops, which is not publicly available. Some of the requests made from our Flash app end up truncated when we read the response. Running with FireBug or Fiddler to monitor the requests makes the problem go away. Setting asyncInit to false also appears to fix things. It is worth noting that the request that is truncated is made well after the plugin is loaded in our case.
Hi, I'm writing to say that we think we have found how to fix this problem in our Flash-server communication. We had no Content-Type header in our responses; when we added it, responses seemingly started to get fully loaded. Both application/xml and text/plain values worked.

I suggest looking into how Firefox response loading may sometimes fail if there is no content type.
I can confirm that v42 is working fine and that disabling dom.ipc.plugins.asyncInit make it work in v40
Marking as dup. We should verify this report on the fixed 41 beta build if possible.
Closed: 9 years ago
Flags: qe-verify+
Resolution: --- → DUPLICATE
Venant, Sergejs: Does it work with Firefox 41 beta 5 [1] without the workarounds? 
I tried to reproduce with Firefox 40RC, but it doesn't reproduce there anymore as the links were changed.


Flags: needinfo?(venant.tang)
Flags: needinfo?(knuckleslives)
Reverted to the old code to check on an environment where server's response type is not set.
Firefox 41.0b5 with asyncInit=true (default) - working
Firefox 41.0b5 with asyncInit=false - hangs up consistently. Both when response type is set and not set
Firefox 40.0.3 with asyncInit=true - was working for many attempts, but the error (unfinished responses) started reproducing later
Firefox 40.0.3 with asyncInit=false (default) - working. Couldn't reproduce unfinished responses today.

Previously when I was having the issue:
Firefox 40.0.3 with asyncInit=true - was hanging up consistently
Firefox 40.0.3 with asyncInit=false (default) - error was reproducible (unfinished responses)

Not sure what to make of these tests, the nature of responses not being fully loaded is erratic, also can't explain the browser freezes and hang-ups.
Flags: needinfo?(knuckleslives)
(In reply to Petruta Rasa [QA] [:petruta] from comment #18)
> Venant, Sergejs: Does it work with Firefox 41 beta 5 [1] without the
> workarounds? 
> I tried to reproduce with Firefox 40RC, but it doesn't reproduce there
> anymore as the links were changed.
> [1]
> build1/
> Thanks!

Yes, it is working with v41.b5
Flags: needinfo?(venant.tang)
Aaron, can you please take a look at comment 19?
Please let me know if there's anything I could do to help.
Flags: needinfo?(aklotz)
Async init is on hold, so we don't need to do anything at the moment.
Flags: needinfo?(aklotz)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.