venant Reporter
	Description • 9 years ago

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
2.Launch http://wccqa.on24.com/view/presentation/flash/EventConsoleSetup.html?profiletype=player&cb=on24&eventId=1053438&sessionid=1&displayMode=update&key=F1F1275F4ACDABEC0B3B957FEF8449F0&text_language_id=en&localeCountryCode=null&eventtheme=orange&pagetitle=Setup%20Event%20Console%20%28Player%29%20Page#



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?

	Loic
	Comment 1 • 9 years ago

I'm able to load the Flash applet in FF40 with Flash 18.0.0.232, I don't see any error.

Which version of Flash player are you using?

In addition, is it reproducible with a fresh profile?
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

	welf.warnecke
	Comment 2 • 9 years ago

Hi,
I have the same problem with Firefox v.40 and Flash 18.0.0.232. 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 .

	Loic
	Comment 3 • 9 years ago

Welf, do you have a simple testcase to reproduce the issue?
COuld you give STR?

	welf.warnecke
	Comment 5 • 9 years ago

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.

	venant Reporter
	Comment 6 • 9 years ago

(In reply to Loic from comment #1)
> I'm able to load the Flash applet in FF40 with Flash 18.0.0.232, I don't see
> any error.
> 
> Which version of Flash player are you using?
> 
> In addition, is it reproducible with a fresh profile?
> https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles

The flash version is the latest 18.0.0.232. 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.

http://wccqa.on24.com/view/presentation/flash/EventConsoleSetup.html?profiletype=player&cb=on24&eventId=1053438&sessionid=1&displayMode=update&key=F1F1275F4ACDABEC0B3B957FEF8449F0&text_language_id=en&localeCountryCode=null&eventtheme=orange&pagetitle=Setup%20Event%20Console%20%28Player%29%20Page&fallbackCallForWidgetLibraryUrl=false

	Loic
	Comment 7 • 9 years ago

venant, thanks for the link. Indeed, sometimes the Flash application never loads, sometimes it does.
And the response of http://wccqa.on24.com/utilApp/WccWidgets is incomplete when it fails:

<?xml version="1.0" encoding="UTF-8"?><widgets><widget xmlns:ns2="http://vshow.on24.com/ns/api/v1"><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="http://vshow.on24.com/ns/api/v1"><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 https://www.mozilla.org/en-US/firefox/developer/all/) and Nightly (43, see https://nightly.mozilla.org/) to confirm it's fixed on your side.

	Loic
	Comment 8 • 9 years ago

welf.warnecke, could you test too, please.

	venant Reporter
	Comment 9 • 9 years ago

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.

	Loic
	Comment 10 • 9 years ago

See the calendar: https://wiki.mozilla.org/RapidRelease/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.

	Loic
	Comment 11 • 9 years ago

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.

	Sergejs
	Comment 13 • 9 years ago

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 https://apps.facebook.com/slots_farm, 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. 18.0.0.232) 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: http://i.imgur.com/VUntRr5.jpg (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.

	Josh Goldshlag
	Comment 14 • 9 years ago

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.

	Sergejs
	Comment 15 • 9 years ago

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.

	mohamed.bgb
	Comment 16 • 9 years ago

I can confirm that v42 is working fine and that disabling dom.ipc.plugins.asyncInit make it work in v40

	(No longer employed by Mozilla) Aaron Klotz
	Comment 17 • 9 years ago

Marking as dup. We should verify this report on the fixed 41 beta build if possible.

	Petruta Horea [:phorea], Desktop QA
	Comment 18 • 9 years ago

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] https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/41.0b5-candidates/build1/

Thanks!

	Sergejs
	Comment 19 • 9 years ago

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.

	venant Reporter
	Comment 20 • 9 years ago

(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]
> https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/41.0b5-candidates/
> build1/
> 
> Thanks!

Yes, it is working with v41.b5

	Petruta Horea [:phorea], Desktop QA
	Comment 21 • 9 years ago

Aaron, can you please take a look at comment 19?
Please let me know if there's anything I could do to help.

	(No longer employed by Mozilla) Aaron Klotz
	Comment 22 • 8 years ago

Async init is on hold, so we don't need to do anything at the moment.