Closed Bug 1194958 Opened 9 years ago Closed 9 years ago

Flash game FarmVille 2 doesn't load on Firefox 40 with Asynchronous Plugin Initialization enabled

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
40 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox40 wontfix, firefox41+ fixed, firefox42+ fixed, firefox43+ fixed)

Status:
RESOLVED DUPLICATE of bug 1194600
Tracking Flags:
Tracking Status
firefox40 --- wontfix
firefox41 + fixed
firefox42 + fixed
firefox43 + fixed

People

(Reporter: sarvesh.n, Unassigned)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150807085045 Steps to reproduce: Load http://apps.facebook.com/farmville-two , the game loads only when the cache is cleared. In Firefox 39 and Firefox 43 nightly build this works fine upon multiple reloads, clearly indicates some browser cache issue specific to Firefox 40 Actual results: Application doesnt load Expected results: It should work like Firefox 39
Could you make a test: 1) in safe mode: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode 2) with a fresh profile: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles Does it work?
Flags: needinfo?(sarvesh.n)
I tried both of these and these dont help, I investigated further and did a map local using Charles for the url below https://zynga1-a.akamaihd.net/farm2/manifest.77edd1cgz The application then starts working fine. This indicates that Firefox 40 cache is incorrectly storing the above file in the cache The response header for this file has Content-type:gzip Can it be that Firefox misinterprets the above file because it ends with gz? I googled and found some very old issues for files ending in gz http://stackoverflow.com/questions/30292868/firefox-fails-to-decompress-gzip-files
Flags: needinfo?(sarvesh.n)
The same application works fine in IE, Chrome, Safari, Firefox 39 and other browsers Below is another similar bugid I found, but I am not sure if it is the same thing or whether it has been fixed in Firefox 41 or uncovered? https://bugzilla.mozilla.org/show_bug.cgi?id=233047 Can you let me know?
What response header should the server ideally be passing for Firefox 40 to correctly interpret and handle this situation? (At the same time not breaking other browsers which are currently working fine) Why does Firefox 40 behave in this manner as compared to Firefox 39 and other browsers? Has there been some change wrt cache handling in Firefox 40? Can you point me to the Firefox source commit in that case?
If it doesn't work in FF40 but in FF43, it's probably a regression bug already fixed. Could you test in FF41 and 42, please.
NB: I tested with FF40 on Win 7, no issue to load the Flash game (even it's long to load).
It loads only first time because the data is not fetched from the cache on first attempt Try reloading and the data would be fetched from cache and you would see the issue.
I tried FF41, it still has the issue and FF39 did not have this issue , as I understand FF43 would be released in December, so can't we fix this more in advance?
I tested with a fresh profile on FF40, FarmVille 2 fails to load when Asynchronous Plugin Initializationis enabled (dom.ipc.plugins.asyncInit=true by default). If it's disabled, it works. I tested with FF42/43 and it appears to be already fixed, but I failed to find the bugfix with Mozregression.
Status: UNCONFIRMED → NEW
Component: Untriaged → Plug-ins
Ever confirmed: true
Product: Firefox → Core
Summary: Firefox 40, Applciation works only when you clear the browser cache, it was fine in Firefox 39 → Flash game FarmVille 2 doesn't load on Firefox 40 with Asynchronous Plugin Initialization enabled
EDIT: Forgot the last line my previous comment. Mozilla disabled by default the API feature in Aurora/Nightly, that's why it works (and seems to be fixed), but if you enable API, it fails like in Release/Beta. So it's clearly not fixed in FF42/43.
Blocks: asyncplugininit
status-firefox40: --- → affected
status-firefox41: --- → affected
status-firefox42: --- → affected
status-firefox43: --- → affected
tracking-firefox40: --- → ?
tracking-firefox41: --- → ?
tracking-firefox42: --- → ?
tracking-firefox43: --- → ?
Keywords: regression
Agree, I tested too, setting the above flag fixes the issue, so would it be possible to push out an interim fix in the next minor version, presently this is affecting a lot of players on Firefox
Check bug 1116806 for the follow-up.
Hi, we have more details on this. Our game is not loading after it gets into firefox cache too. https://apps.facebook.com/elementverge We found that it's because the loaded content from cache trying to load partly from server using Range, Content-Range headers. On following screenshot you could see a lot of 206 statuses on game resources. https://gyazo.com/663016020e940a22503052714441cc66 This affects firefox on Linux and Windows version 40, 41b and 43 nightly If the dom.ipc.plugins.asyncInit is set to true. Turning it to false fix the issue.
Please report this on the master bug -- https://bugzilla.mozilla.org/show_bug.cgi?id=1116806 They are planning to push out a hotfix but not sure when
Tracking for 42+ though it looks like the main bug we're tracking for now is bug 1195609. We should verify the fix in this bug once it rolls out, though.
tracking-firefox42: ? → +
tracking-firefox43: ? → +
I believe this is fixed now from the hotfix in bug 1196078. Dima, is your game working now in the current Nightly build? sspn, can you verify that this is working now for you?
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(sarvesh.n)
Flags: needinfo?(dima.bezverkhiy)
Resolution: --- → FIXED
Thanks a lot! It is fixed now, is there some way I could get notifications of such future changes related to NPAPI, Plugins, Flash that will happen on Firefox?
Flags: needinfo?(sarvesh.n)
It works for our production servers with asyncInit set to true in firefox 40.0.2 But for our development enviroment it is still not loading the content correctly. Try to go to http://preprod-el.imm.mimimigames.com/preprod_el5_all/html_client/?uid=mol33&network=preprod The first time it would load correctly. After a few refreshes when it is trying to get content from cache it some times give 200 but load not all the bytes and sometimes 206 with range of bytes in headers. https://gyazo.com/88df597b8295896d073d672a29eb70da It's the same on Win 7 64bit and Linux On mac everything works fine.
Flags: needinfo?(dima.bezverkhiy)
Sorry forget to note that to go to our dev servers you need to accept certificate from here https://preprod-el.imm.mimimigames.com/
Sorry, for missunderstanding. If the hotfix automatically changes asyncInit parameter from true to false. That would fix the problem because it works with as expected with this parameter set to false.
Should we keep this as Resolved Fixed? Note that this wasn't actually fixed, it was just that we disabled Async Plugin Init. If we still want to release Async Plugin Init then we should look for an actual fix with this enabled.
Flags: needinfo?(lhenry)
Yes, I dont think it should be marked as fixed till we solve the actual issue. We should attach this to the master list of issues associated with the flag being turned to On. So that in case we release FF41 witht he flag turned on we need to resolve this first.
(In reply to sspn from comment #25) > Yes, I dont think it should be marked as fixed till we solve the actual > issue. > > We should attach this to the master list of issues associated with the flag > being turned to On. > So that in case we release FF41 witht he flag turned on we need to resolve > this first. This is already attached to the master list of issues with Async Plugin Init enabled (bug 1195607), yet none of the other issues are marked fixed.
(In reply to sspn from comment #19) > Thanks a lot! It is fixed now, is there some way I could get notifications > of such future changes related to NPAPI, Plugins, Flash that will happen on > Firefox? https://lists.mozilla.org/listinfo/dev-tech-plugins
The fix in bug 1194600 takes care of this bug.
Florin: I see your point and you are probably right here. We should keep this open to make sure that when asyncplugin init is enabled again, we can verify that this is really fixed. I'll re-open and wontfix it for 40. That would make more sense. My reasoning was: this came up in bugmail. I wondered, if we went to the effort to ship the hotfix, how we know that it is really fixed. I think here we should go with, if it's still a problem, the users will tell us. It seems unlikely that we can verify each of these bugs for the hotfix, then verify them again later. Aaron, hope that's ok with you and makes sense to you as well.
Status: RESOLVED → REOPENED
status-firefox40: fixed → wontfix
Flags: needinfo?(lhenry)
Resolution: FIXED → ---
I'm cool with this. I might eventually mark it as a dupe of bug 1194600 but we'll still want QA verification of this bug's test case. FWIW it looks good to me on my locally patched build.
It would be good to verify this is fixed in the next 41 beta.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
status-firefox41: affected → fixed
status-firefox42: affected → fixed
status-firefox43: affected → fixed
Flags: qe-verify+
Resolution: --- → DUPLICATE
Reproduced with both links using Firefox 40RC. Verified as fixed with Firefox 41 beta 5.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.