1317995 - Firefox 50 64-bit Stable channel is unable to play Farmville 2 Facebook Flash game.

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Jukka Jylänki]

Zynga reported to us that Farmville 2 on Facebook is currently broken in Firefox 50.0 64-bit Stable channel.

As an STR one can visit https://apps.facebook.com/farmville-two/ to test. The game loading bar will hang at about 75%.

Overall:
 - Firefox 49 32-bit+64-bit works
 - Firefox 50 32-bit works
 - Firefox 51 32-bit+64-bit works

but

 - Firefox 50 64-bit doesn't work

Bisected the fix to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=da083c6367526ab8d30d1b07b94b2c56b77d7831&tochange=c941e8a139541661f1ca69c673959345e76f20bf,

which strongly suggests this as the fix:

https://bugzilla.mozilla.org/show_bug.cgi?id=1283274

Oddly, I see an uplift for Firefox 49 there in comment 20. Did that commit get uplifted to Firefox 49 from Firefox 51, but the fix slipped from getting in to Firefox 50 (64-bit)?

Comment 1

[Jukka Jylänki]

To clarify, this is a regression that has been fixed by above commit. The question here is whether we can uplift the fix to also patch current Firefox 50.0 64-bit?

Comment 2

[Benjamin Smedberg]

The situation is that we're willing to ship two configurations on win64:

* async drawing enabled (Flash always runs in windowless mode, with accelerated drawing)
* Flash forced to windowless mode

We are not willing to ship Flash running in windowed mode on win64, because of concerns around sandboxing and regressions in IME and other areas.

In Firefox 49 we shipped async drawing, and there were major functional and performance regressions. So in Firefox 50 we're switching back to forcing Flash to windowless mode.

So we did not forget to uplift bug 1283274, and we're shipping the configuration we expect to ship.

Farmville should test by adding wmode="opaque" manually, and if that shows the error, then they need to figure out why using windowless mode would cause their SWF to hang.

Comment 3

[Benjamin Smedberg]

And to be clear: Firefox 51 aurora works because async drawing is preffed on for nightly and aurora.

Comment 5

[Alice0775 White]

Regression window(forcing dom.ipc.plugins.asyncdrawing.enabled = false as default of release50/beta51)
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=ca14ab5a7f99b1d7caf841868ee46188fb44f5db&tochange=075f767684d1c02759e72b69d0b565fbbc002a4e

Suspect: 36b88fa83de9	Jim Mathies — Bug 1312530 - Force windowless plugin mode in 64-bit builds if async rendering is disabled. r=akotz, a=ritu

Comment 6

[Benjamin Smedberg]

That's not an interesting regression range, we were changing back to the Firefox 48 configuration.

Comment 7

[Alice0775 White]

So, Bug 1318385 is not a dupe.

Comment 8

[Benjamin Smedberg]

On the contrary, it *is* a duplicate. The landing of 1312530 is the proximate cause of this, but as I said in comment 2, the fundamental problem lies elsewhere.

Comment 10

[Abe - QA (:Abe_LV)]

Yes, FarmVille2 is not working in nightly. Here is the regression range for 64 bits Firefox in Windows-10.
Game url: https://www.facebook.com/FarmVille2/

Last good revision: c1dd8b9b9915ba53fc4e2cb34e091ab7a1b514ea
First bad revision: fea5300238497189b0823fe4a1a09154a384ebc7
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c1dd8b9b9915ba53fc4e2cb34e091ab7a1b514ea&tochange=fea5300238497189b0823fe4a1a09154a384ebc7

Looks like the following bug has the changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1269807.

Comment 11

[Abe - QA (:Abe_LV)]

I got the same regression range for 32 bits of Firefox nightly in 64 bits of Windows 10.
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

Comment 12

[Kohei Yoshino]

Other reports on Firefox Input: https://input.mozilla.org/en-US/?q=Context3D&product=Firefox&version=50.0

Comment 13

[Jukka Jylänki]

(In reply to Abe - QA (:Abe_LV) from comment #10)
> Yes, FarmVille2 is not working in nightly. Here is the regression range for
> 64 bits Firefox in Windows-10.

Current Firefox Nightly not being able to run Farmville 2 seems to be a separate issue, which was marked down as https://bugzilla.mozilla.org/show_bug.cgi?id=1317984. The symptom of that bug is that the whole Flash canvas stays white, and none of the Flash content displays. In this bug 1317995, the issue is a different one, where the game does start up and display properly, but it hangs at the loading bar stage at around 75%. (In both cases the background music does keep playing uninterrupted)

(In reply to Benjamin Smedberg [:bsmedberg] from comment #2)
> The situation is that we're willing to ship two configurations on win64:
> 
> * async drawing enabled (Flash always runs in windowless mode, with
> accelerated drawing)
> * Flash forced to windowless mode
> 
> We are not willing to ship Flash running in windowed mode on win64, because
> of concerns around sandboxing and regressions in IME and other areas.
> 
> In Firefox 49 we shipped async drawing, and there were major functional and
> performance regressions. So in Firefox 50 we're switching back to forcing
> Flash to windowless mode.
> 
> So we did not forget to uplift bug 1283274, and we're shipping the
> configuration we expect to ship.
> 
> Farmville should test by adding wmode="opaque" manually, and if that shows
> the error, then they need to figure out why using windowless mode would
> cause their SWF to hang.

Thanks for the details here, good info. Is there documentation somewhere about the wmode="opaque" entry, what it does, and why it would be expected to help here?

You mention that we are shipping the expected configuration in Firefox 50 64-bit. Given that current Firefox Dev Edition & Nightly 64-bit branches don't have this issue, are they currently shipping with incorrect configuration? The following comment suggests it's intentional:

(In reply to Benjamin Smedberg [:bsmedberg] from comment #3)
> And to be clear: Firefox 51 aurora works because async drawing is preffed on
> for nightly and aurora.

What is the rationale for shipping a different configuration in Nightly and Dev Edition, but not in Stable and Beta? Wouldn't it make these kinds of scenarios continuously look as if Stable&Beta were buggy, but next train coming from Dev Edition would fix the issue. If we don't intend to ship with async drawing enabled, why have it enabled in Dev Edition and Nightly? Or is the intent that we will eventually ship async drawing enabled so it's pre-empted to be on in DE&Nightly because of that?

Comment 14

[Benjamin Smedberg]

> Thanks for the details here, good info. Is there documentation somewhere
> about the wmode="opaque" entry, what it does, and why it would be expected
> to help here?

See Adobe docs at https://helpx.adobe.com/flash/kb/flash-object-embed-tag-attributes.html#main_Using_Window_Mode__wmode__values_

wmode=opaque switches Flash from "windowed" mode where it uses a native windows widget (HWND) to a windowless mode where it draws into the browser's widget. Due to the security sandbox in win64, we must force all Flash to use windowless mode rendering.

> What is the rationale for shipping a different configuration in Nightly and
> Dev Edition, but not in Stable and Beta? Wouldn't it make these kinds of

The point of this is that the new feature needs testing but is still less stable, and so we're shipping it to prerelease to get bug reports and solve issues. Beta ships in the release configuration. Eventually we will decide to ship async drawing back to beta/release once we've resolved the bugs.

Comment 15

[Andrew Overholt [:overholt]]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #14)
> The point of this is that the new feature needs testing but is still less
> stable, and so we're shipping it to prerelease to get bug reports and solve
> issues.

I'm confused. Is 50 (current release) 64-bit still broken?

Comment 16

[Matt Samet]

Hi guys, is there any update on this issue?

Comment 17

[Benjamin Smedberg]

My understanding is that next steps are in Zynga's court, since this game doesn't work properly in windowless mode.

Comment 18

[Benjamin Smedberg]

To be extra-clear: the status of Firefox 50 on win64, and future betas and releases for now is: async rendering is disabled. Firefox will force all Flash content into windowed mode, using wmode="opaque" if there is no wmode specified.

Work for turning async rendering back on is tracked in the bug tree at https://bugzilla.mozilla.org/showdependencytree.cgi?id=1229961&hide_resolved=1

Comment 19

[Jukka Jylänki]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #17)
> My understanding is that next steps are in Zynga's court, since this game
> doesn't work properly in windowless mode.

I'm not sure if that reasoning concludes that it must be a game bug? Why couldn't this be a Firefox or a Flash player bug? (I don't know much about Flash, though perhaps there's a pattern to these windowed vs windowless behavior I'm not aware of?)

The Flash documentation page on how wmode operates doesn't either give much clues towards the hang, e.g. there's no documented limitations/differences except mentions about accessibility, performance and layering with other HTML elements, but nothing that would hint of missing API features or functionalities that could lead to this kind of hang that the game should be aware of. If the game is using some construct that is unsupported in wmode="opaque" mode, then we could certainly call it a game bug, but I'm not sure if we have concluded that?

Matt, do you know if there might be something the game code is doing that might not be compatible with wmode="opaque"? Can you try explicitly setting the game run in wmode="opaque" mode and see if it runs in Flash players in general? I wonder if we'd be able to triage if it could be an issue in Firefox support for wmode="opaque" mode, or if the game exhibits the hang in all browsers/Flash players when using wmode="opaque" mode.

Also, any way you'd be able to identify what operation the game is doing when it hangs? Hopefully that would offer some insight into where things are going wrong.

Comment 20

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

NI'ing Matt — based on Jukka's question in Comment 19

Comment 21

[Matt Samet]

Sorry I don't have all the necessary context here, but I've asked the people on the FarmVille team to reply.

Comment 22

[Liz Henry (:lizzard) (relman/hg->git project)]

Giri and Sarvesh replied via email and I am connecting them with Jukka.

Comment 23

[bilalgce]

(In reply to Jukka Jylänki from comment #19)
 
> Matt, do you know if there might be something the game code is doing that
> might not be compatible with wmode="opaque"? Can you try explicitly setting
> the game run in wmode="opaque" mode and see if it runs in Flash players in
> general? I wonder if we'd be able to triage if it could be an issue in
> Firefox support for wmode="opaque" mode, or if the game exhibits the hang in
> all browsers/Flash players when using wmode="opaque" mode.

Our game hangs if we explicity set wmode="opaque" in other browsers too. Is there any way we can force wmode=direct in firefox 64 bit?

> Also, any way you'd be able to identify what operation the game is doing
> when it hangs? Hopefully that would offer some insight into where things are
> going wrong.

We're checking it and will get back soon.

Comment 24

[Liz Henry (:lizzard) (relman/hg->git project)]

From email discussion, sounds like this may still be a problem in 53/54 even with async drawing enabled. 
Chris, do you know if that's true? We can ask for more testing here if that would be helpful.

Comment 25

[Liz Henry (:lizzard) (relman/hg->git project)]

Jimm, you mentioned in an email thread that Farmville 2 may not work with 64-bit even with async drawing enabled. Is that still the case? Can you explain here or point us to a relevant bug?

Comment 26

[Chris Peterson [:cpeterson]]

Jim said in email "Async drawing fixes the problem so when that rolls out as the default, the problem should go away." The discussion about fixing Farmville 2 to work with wmode=opaque was a proposed workaround for 64-bit before we re-enable Flash async drawing (bug 1340934).

Comment 27

[Jim Mathies [:jimm]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #25)
> Jimm, you mentioned in an email thread that Farmville 2 may not work with
> 64-bit even with async drawing enabled. Is that still the case? Can you
> explain here or point us to a relevant bug?

Should render. There are some mouse wheel input problems with the page on facebook that don't block. I don't have a bug on that yet.

Comment 28

[Jim Mathies [:jimm]]

fixed in dev channels. fix will roll out with async drawing (bug 1345649).