问题描述：
下午遇到个麻烦：IE7和IE8会拦截flash中navigateToURL(’xxx’,'_blank’);
as2下的getURL一样被拦截。
貌似曾经遇到过这情况，但并不是经常出现，所以一直没去研究被拦截的条件。今天又出现了，正好找找原因。
搜索一番，发现很多去年的讨论。
有人指出：
IE7和Firefox（我使用的版本是2.0.0.11）会阻止用navigateToURL方法打开新窗口，而AS2中的getURL方法则不会，让人很不爽。既然项目选择了AS3开发，就只能想办法来解决。
首先当然想到的是ExternalInterface了，测试发现还是会被blocked。后来想添加wmode会不会有所帮助，于是在页面中添加wmode属性为opaque，果然OK了。
现提供AS3中的getURL方法：
function getURL(url:String,window:String=”_blank”):void{ var broswer:String=ExternalInterface.call(”function getBrowser(){return navigator.userAgent}”) as String; if(broswer.indexOf(”Firefox”)!=-1 || broswer.indexOf(”MSIE 7.0″)!=-1){ ExternalInterface.call(’window.open(”‘+url+’”,”‘+window+’”)’); }else{ navigateToURL(new URLRequest(url),window); }}
使用方法跟AS2中的getURL一样。另外，我只测试了IE6/7，Firefox2，并未对Safari等其他浏览器做测试。最后，最最重要的就是在 html中把flash对象设置wmode属性为opaque或transparent。因为wmode属性默认为window，这表明此Flash应用程序与HTML层没有任何交互。
上文的思路是用as call js来实现弹窗，这需要配合wmode=’opaque’或者wmode=’transparent’。
可是现在时代已经不同，游戏规则又变化了，上文的方法已经不再适用。
我刚测试，
火狐3.5.3测试是不会拦截的。
用IE7和IE8测试都被拦截。
真奇怪，有这种事情！于是我把收藏的几个Flash酷站整出来一个个看过去，发现其中apsou的网站上有_blank的内容不会被拦截~
调查了其网页的代码，发现和众多会被拦截的网站有一点不同：wmode。
解决方案：
终于发现通过设置wmode可以解决问题：当wmode=’window’（默认值）的时候，IE就不再拦截了。
这也许和ie下activeX的机制有关吧。
上面引用的文章中提到的 “最最重要的就是在 html中把flash对象设置wmode属性为opaque或transparent” 这个也不用太担心。wmode为window的时候仍然可以call js。
虽然有解决方法了，可是我又很不情愿把wmode改成window。看来我还得和js通信，让js那边负责绕过拦截。
不过仔细想想其实问题不大，因为我们国内的网友的局势很有趣。
一般用火狐或者IE7+或者safari、Google Chrome的都是爱赶潮流的，或者是玩过各种web2.0产品的，算是高端一些的网民。这批人都懂得屏蔽是个啥意思，“屏蔽弹窗”这样的善意功能也能更好地起作用。这批人往往都会设置白名单，所以并不需要担心他们由于浏览器屏蔽而访问不了内容。
而剩下的大部分使用XP+原装IE6的用户，很多并不是对网络很有热情，正好这部分用户的浏览器也不会拦截我们flash，他们也不用学会网络过滤设置。
嘿嘿，各司其位，自然和谐。
几种wmode的不同
额，顺便罗列一下wmode的几点不同。总结了几种wmode有什么不同，各自符合什么情况使用：
Window是默认的,窗口模式，吃CPU不严重
Transparent透明无窗口模式
Opaque不透明无窗口模式
效率最高的是window模式
透明用transparent
而需要动态交互(比如js)或者window模式不稳定的情况下用opaque
Window和transparent在ie6的iframe下拖动会出现花屏——个人经验。
还有一点，无窗口模式消耗资源大，但是能保证帧频