I can reproduce this with Flash player 188.8.131.52 32bits version for IE but not with the 64 bits version neither the peperflash 32 bits version.
Settting EnableInsecureActiveXNavigateToURL=1 in mms.cfg file is a workaround.
But I can't find any information about this parameter.
ExternalInterface.call("window.open", url, window);
The most likely reason that this broke your content is because the URL in the call to NavigateToURL is no longer considered as coming from the same origin as the page hosting the SWF.
The right solution is to modify your content to handle the fact that the communication is no longer automatically permitted as a same-origin request. Depending on what you're doing and what your preferences are, your approach to that would vary (e.g. if you're navigating to a file over UNC paths to the same host that's serving the parent page over HTTPS, then you might want to load that file over HTTPS to keep it same-origin).
Because pre-announcing these kinds of changes is effectively just declaring "use it, or lose it" to attackers, we don't. The next best approach is to gate the legacy behavior behind a flag, so that for the tiny subset of users that are affected by this kind of change, they can buy some time while they sort the issue out in their application. The goal with these kinds of things should always be to wean yourself off as soon as possible (that's why we chose the EnableInsecure* naming), but they exist as pain-relief that your operational teams can employ while you pursue any necessary engineering or architectural changes.
Thank You for providing details.
What we have observed is that there is a difference in behaviour when embedding the SWF in a browser compared to WebBrowser controller (.Net Component). The same application is working when opened in a browser but not working when launched in WebBrowser. Following is a defect which is similar to what we are looking for,
Please provide your inputs on this defect. If this is a valid defect ?
Thank you for the response, I have a related question to this issue. We are trying to address application behaviour that has stopped working since 184.108.40.206. So understand that it is not detecting that our calls to navigateToURL are failing as not being in the same domain.
Is there guidance or an example of how to approach this, ie could we use the crossdomain.xml policy to flag our interactions as being allowed until we can re-architect the application?
The other option is the ExternalInterface.call() as posted by jeromebillet, however not sure if that is viable longer term.