921837 - Flash Externalinterface addCallback can't be established when replacing swf

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[greg]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

i set up a small demo page to best demonstrate this.
https://dl.dropboxusercontent.com/u/11385083/problem2/index5.html

the "download it" link will provide a zip file containing all the files. 
i'm testing with firefox ver 24 on multiple pcs.  the page opens with a swf.

1. click the "stop" button several times.  the swf toggles between playing and being stopped using an ExternalInterface.addCallback function.

2. click the "next page" button.  the swf is replaced via javascript with a new identical swf.

3. click the "stop" button.  new swf no longer responds.


Actual results:

after first loading the page, you can click the "next page" button as many times as you like before clicking the "stop" button, at which point, the stop button will work fine on the current swf.  click "next page" again though, and it breaks.  so basically, once you use the ExternalInterface.addCallBack function, you can't swap the swf file out and have it establish itself with a new swf.


Expected results:

at first i suspected my swf-swapping code, but since i can swap as many times as i like without it breaking, that seems ok.  and this problem doesn't occur in explorer or chrome.  we develop web-based e-learning courses and are mostly concerned that our stuff runs correctly in firefox and explorer though so, any help you guys could offer would be really really really appreciated.  thanks,

Comment 1

[the-edmeister]

I can confirm this issue with the demo page.

Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0 ID:20130910160258 CSet: 7c3b0732e765

Comment 2

[Till Schneidereit [:till]]

Greg, thanks for reporting this. Do you happen to know if this used to work in earlier versions of Firefox? If not, would you be willing to try out older versions and see if it did?

You can find those here:
https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/


CC-ing bsmedberg as he might know what's going on here.

Comment 3

[Georg Fritzsche [:gfritzsche]]

(In reply to greg from comment #0)
> Actual results:
> 
> after first loading the page, you can click the "next page" button as many
> times as you like before clicking the "stop" button, at which point, the
> stop button will work fine on the current swf.  click "next page" again
> though, and it breaks.

Works for me on Firefox Nightly (nightly.mozilla.org) on OS X & Windows 7.
Can you confirm? Does it work for you on Aurora (Fx 26) & Beta (Fx 25)?

http://www.mozilla.org/en-US/firefox/aurora/
http://www.mozilla.org/en-US/firefox/beta/

Comment 4

[Till Schneidereit [:till]]

Works for me, too. (And I would've said as much earlier, if I hadn't accidentally tested with Shumway. Interestingly, it doesn't work with that, while stopping/starting the animation before clicking on next does work.)

Comment 5

[greg]

hey till, thanks.  oh my gosh you guys have to do some confusing work.  happy to georg fritzsche said it works on firefox nightly so maybe...  but i see he also said win7, and i'm running win8, so maybe something there.

yes, thanks for the link, and i'd be happy to try some earlier versions, i can probably even try win7 vs win8, but i won't be able to get to it 'til tomorrow (thursday) evening.  unless somebody screams at me not to bother, i'll go ahead and do that and report back in.  thanks again,



(In reply to Till Schneidereit [:till] from comment #2)
> Greg, thanks for reporting this. Do you happen to know if this used to work
> in earlier versions of Firefox? If not, would you be willing to try out
> older versions and see if it did?
> 
> You can find those here:
> https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/
> 
> 
> CC-ing bsmedberg as he might know what's going on here.

Comment 6

[greg]

well...  sorry i hadn't seen anything about the nightly stuff before, but yes, i've checked the nightly build (firefox-27.0a1.en-US.win32.installer.exe) and it looks like it's working on both win7 and win8.  

had already done some testing of earier versions, but hadn't seen it working in anything earlier.  so i guess this means somebody fixed the bug just as i was writing my bug report?  does this mean i don't get my jillion-dollar reward for finding a bug?  dang!

anyway, any way of knowing when this'll come out in a release?  i just know people will ask.

thanks everybody for your support.  it's really really really appreciated.


(In reply to Georg Fritzsche [:gfritzsche] from comment #3)
> (In reply to greg from comment #0)
> > Actual results:
> > 
> > after first loading the page, you can click the "next page" button as many
> > times as you like before clicking the "stop" button, at which point, the
> > stop button will work fine on the current swf.  click "next page" again
> > though, and it breaks.
> 
> Works for me on Firefox Nightly (nightly.mozilla.org) on OS X & Windows 7.
> Can you confirm? Does it work for you on Aurora (Fx 26) & Beta (Fx 25)?
> 
> http://www.mozilla.org/en-US/firefox/aurora/
> http://www.mozilla.org/en-US/firefox/beta/

Comment 7

[Georg Fritzsche [:gfritzsche]]

Good to hear it's working for you in nightly too.
I don't know offhand which bug might have fixed this, may you could help narrowing it down using mozregression [1]?

[1] http://mozilla.github.io/mozregression/

Comment 8

[Till Schneidereit [:till]]

(In reply to greg from comment #6)
> anyway, any way of knowing when this'll come out in a release?  i just know
> people will ask.

Version 27 will be released about 16 weeks from now. That's based on the release model described here: https://hacks.mozilla.org/2012/05/firefox-and-the-release-channels/

So, I'm sorry to say that this bug will stay unfixed for quite a while still. We can only do a limited amount of fixing things in versions that have moved on from the active development phase without seriously affecting the speed at which we can develop new features and fix bugs in general.

Comment 9

[Emanuel Hoogeveen [:ehoogeveen]]

If you can find the bug that fixed this, it might be possible to get it uplifted to Firefox 26 (current Aurora) - don't hold your breath though: the more complicated and risky the fix, the less likely it is to get uplifted, and the requirements are pretty strict.

Comment 10

[Bogdan Maris, Desktop Test Engineering]

I was unable to reproduce the issue on Firefox 26RC, latest Aurora 28.0a2 and latest Nightly 29.0a1 using Windows 8.1 x64. Marking this as resolved worksforme. If someone can still reproduce please reopen the bug.

Comment 11

[schulz]

Hello,

since a view days, we have the same problem greg described. But first we have to clarify that we have two Application cases:

case 1: access via a real webserver
- No problems found, communication via the ExternalInterface works in both directions Flash to JavaScript and JavaScript to Flash. This is the common way of course and the reason why this bug has the state "resolved worksforme".

case 2: access via the file protocol
Sometimes our customers need a version they can use offline from CD-ROM or USB-stick. And here the problem accurs.
- Communication from Flash to JavaScript works fine.
- Communication from JavaScript to Flash doesn't work in Mozilla Firefox anymore (since???)! But notice! For safety reasons there were always a vew steps to do in the FlashPlayer settings. There are two ways to do this settings.
a) doing the security settings manually:
- right click on a flash content in the browser > choose "global settings"
- choose the last tab "Advances"
- scroll down to "Trusted Location Settings"
- here you can add trusted pages or folders

b) doing a path entry in a file in the "FlashPlayerTrust" directory:
Because a) is not reasonable for our customers we build a launcher that does the following steps automatically.
- locate C:\Users\<username>\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust\
- there you can create a file "anyName.cfg" where you can define several paths of your local flash content that is treated as trusted from FlashPlayer e.g. E:\Applications

You can still test it with the demo-project from greg above:
https://dl.dropboxusercontent.com/u/11385083/problem2/index5.html


At the moment we tell our customers to use Internet Explorer.

Thank you,
Matthias

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0

Comment 12

[Georg Fritzsche [:gfritzsche]]

(In reply to schulz from comment #11)
> - Communication from JavaScript to Flash doesn't work in Mozilla Firefox
> anymore (since???)! But notice! For safety reasons there were always a vew
> steps to do in the FlashPlayer settings. There are two ways to do this
> settings.
> a) doing the security settings manually:
> - right click on a flash content in the browser > choose "global settings"
[...]
> b) doing a path entry in a file in the "FlashPlayerTrust" directory:
[...]

Please correct me if i'm wrong, but that sounds like you have an issue with the Flash behavior here, not with Firefox?