Flash apps, that are coded in ActionScript 2.0, are unable to communicate with host page in Firefox due to the removal of "javascript:" support. Flash AS 2.0 apps require "javascript:" in order to call javascript functions on the page. The following snippet is only method for flash apps to communicate with host page in ActionScript 2.0: getUrl('javascript: jsPageCallback(params)'); This is also documented on Adobe website here: http://kb2.adobe.com/cps/141/tn_14192.html#main_ExternalInterface This is a result of bug "527530": https://bugzilla.mozilla.org/show_bug.cgi?id=527530 ------------------------------------------------------------------------ Our situation: We operate Flash Gaming website, and the games communicate with the page via javascript callback function, to authenticate user, notify the page with the score, and update the leaderboard. Unfortunately for us, we have hundreds of games that are coded in ActionScript 2.0 and use getUrl('javascript:') to communicate with the page. Our AS2 Games have stopped working properly on Firefox, but they're working fine on browsers that support 'javascript:', such as Chrome, IE, Opera, Safari.

(In reply to Alaa Shaheen from comment #0) > Flash apps, that are coded in ActionScript 2.0, are unable to communicate > with host page in Firefox due to the removal of "javascript:" support. We haven't dropped support for "javascript:" - as you suggest, that would be quite problematic for web compatibility (for far more than just Flash Apps). What we changed in bug 527530 was very specifically isolated to the loading of "javascript:" URIs using the location bar. Assuming your AS2 Games don't require users to actually type in javascript: URIs in the location bar, the changes associated with that bug shouldn't have had any impact. Do you have a testcase that demonstrates the problem? Do you have any idea when your games stopped working (i.e. between which two Firefox versions?)

First, my apologies for misstating the problem and not being clear. It appears that the problem is not related to 'javascript:' in the Location Bar. After thorough tests, here is the problem as it appears: **Calling local javascript functions on the page from a swf objects does not work when the page --on which the swf object is embedded-- is viewed through an Iframe on different domain/site. And this only applies to the getUrl('javascript: ...') method in ActionScript 2. I have constructed 3 test cases to demonstrate the problem. - Test Case 1: A flash game is embedded on the same page the user views, and everything works fine as expected: When the user finishes playing the game a JS function is called successfully in all browsers, and you'll receive a response in the 'API Response' field. Url: http://www.madgam.es/fb-beta/game_test/Plumet_2/ - Test Case 2: The same page from 'Test Case 1' is viewed through and iframe on an external domain. In our case, the game is viewed through an iframe on Facebook, since we run our games on the Facebook as Iframe apps. In this case the game fails to make javascript callback in Firefox, however, it works well in IE, Chrome, Safari and Opera. Url: http://apps.facebook.com/flash-games-test/ - Test Case 3: The same page from 'Test Case 1' is viewed through and iframe on the same domain. In this case everything works fine as expected: javascript callback is made successfully. Url: http://www.madgam.es/fb-beta/test_game_cb I have tested this issue on Firefox 8, 7, 6, 5, 4 Beta 9, and 3.6... and as it appears, the this issue occurs starting with "Firefox 4 Beta 9", the games were working fine up to Firefox 3.6, however they stopped working afterwards.

(In reply to Alaa Shaheen from comment #2) > I have tested this issue on Firefox 8, 7, 6, 5, 4 Beta 9, and 3.6... and as > it appears, the this issue occurs starting with "Firefox 4 Beta 9", the > games were working fine up to Firefox 3.6, however they stopped working > afterwards. OK, it would be helpful if you could narrow down the 3.6-4.0b9 range further, by testing other 4.0 betas. Once you have a smaller range we can switch to testing nightlies to bisect further.

I have narrowed down the versions and found that the issue started in Firefox 4.0b5. I have then narrowed down the testing by nightly builds and found out that the last working build was on '2010-08-27'. All Firefox pre/releases after the 4.0b5 2010-08-27 build have this issue. Here is a quick summary: 2010-08-01 Firefox 4.0b3 -- Works fine! 2010-08-14 Firefox 4.0b4 -- Works fine! 2010-08-25 Firefox 4.0b5 -- Works fine! 2010-08-26 Firefox 4.0b5 -- Works fine! 2010-08-27 Firefox 4.0b5 -- Works fine! 2010-08-28 Firefox 4.0b5 -- Fails! 2010-08-29 Firefox 4.0b5 -- Fails! 2010-08-30 Firefox 4.0b5 -- Fails! 2010-08-31 Firefox 4.0b5 -- Fails! 2010-09-09 Firefox 4.0b6 -- Fails! 2010-10-01 Firefox 4.0b7 -- Fails! 2010-10-17 Firefox 4.0b8 -- Fails! 2010-12-31 Firefox 4.0b9 -- Fails! ... and so on

> Url: http://apps.facebook.com/flash-games-test/ When I play this and let my character die, the "API response" box shows output and I get an alert, in a current nightly build. I can confirm that it doesn't work in Firefox 8. So it sounds like we have this fixed already....

Looks like the problem disappeared in this checkin range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=630e28e90986&tochange=f69a10f23bf3 Nothing in that range jumps out at me as being responsible, though. Alaa, do you see the problem in a current Beta build? What about a current Aurora build? What were the mercurial changeset ids (from about:buildconfig) for the last working and first non-working build in comment 4?

OK, just like bug 702439 this is an issue with broken UA sniffing on facebook. Using Firefox 8 with the UA string spoofed to say it's Firefox 9 magically makes http://apps.facebook.com/flash-games-test/ work. Alaa, could you please report the issue to Facebook?

Boris, I confirm it's been fixed in the current Beta and Aurora builds. The changeset id for the last working version: e1d55bbd1d1d The changeset id for the first non-working version: 6e3f6d18c124 And the bug is already reported to Facebook, I simply made reference to this bug and bug 702439.

> The changeset id for the last working version: e1d55bbd1d1d > The changeset id for the first non-working version: 6e3f6d18c124 So http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124 Nothing there looks like an obvious culprit; I'll dig around a bit more.

OK, in that range the issue appeared with this checkin: Bug 588874 - Replace Minefield with Firefox in UA string. So yeah, this is a pure UA sniffing issue on Facebook's part...

Alaa, to be clear it's "fixed" in the sense that the current builds are not treated as "Firefox" by facebook's UA sniffer. I fully expect that the moment we ship Firefox 9 they will update their sniffer and break things there, unless they fix the bug on their end.

Hi Boris, You're right about the issue being on Facebook side, and it appears they have fixed the issue. I have tested all not-working versions and they worked like charm! Best Regards.