|
|
|
Actually, I think that this is a Fact of Life until Firefox fixes a bug that doesn't allow this to work. Developers will need to keep using ExternalInterface to call Javascript's window.open() method to get this to work.
Closing bug. No, not a fact of life...
a) externalinterface is not accessible if the .swf is embedded without allowScriptAccess rights. Guess what, not always do we the coders have access to the hosting environment. Thus the workaround is useless in these circumstances. b) _getURL did NOT have this problem in any where near the level that navigateToURL does. So can we resort back to that? Please... I REALLY HATE having to re-write applications I've written in Flex in Flash 7 because of this issue. Also the work-a-round no longer appears to be working in Safari. Perhaps this is due to the update to Safari 3.
I'm providing a link to test. Can you verify if it works for you... http://staging.nxtbook.com/fx/clients/nxtbook/dev/jason/extlink/test.html It works for me in Firefox but not in Safari 3. You can view source, so if there is something that is preventing Safari 3 from working in the code. Please let me know. This now raises the issue to a much much more critical level. Please re-open issue or provide a better work-a-round! Multiple people have commented that, the workaround of calling window.open using ExternalInterface is not working with FireFox 2.0.0.11 and flash player 9.0.115.
http://flexgraphix.com/blog/?p=16 http://skovalyov.blogspot.com/2007/01/how-to-prevent-pop-up-blocking-in.html This is a major, major issue for all widget developers and widget companies. Our businesses are founded on widgets that don't live on our site: ExternalInterface is not an option.
None of us can move to Flash 9 because we can't reliably open windows. Firefox is a platform that has to work! You know, I am getting so annoyed with this stupid navigateToURL() issue. I just want to be able to open up a link in a new browser window. That shouldn't be an ongoing nightmare.
:-( So close, but still no cigar... Started with Firefox pop-up blocker. So I switched to the externalInterface method. That worked, but then Safari 3 came out, and it now longer worked with the method. So I modified it again - which in turn broke Safari 2. I have since modified and refined it further...now I am getting a pop-up blocker in IE. (I think because it doesn't like the conditional logic being used on the click.) *blargh* Here I am, wasting all this time on what Adobe should already have done. Not happy. *** I'm starting to get royally PIEVED OFF!!! I should be developing our application, not developing multiple work-a-rounds for the Flex framework's failure!!! And you guys won't even acknowledge this is a bug. (Outside of being a Firefox bug.) And if it is a Firefox bug, well they're an open source project. How about Adobe drop $100,000 donation to Mozilla to fix the issue in Firefox. Every reference to the navigateToURL getting caught by the pop-up blocker seems to imply it only happens in Firefox. So I must ask: What I am doing so special that I am having the problem in IE as well?
I am using a DataGrid with an itemClick function. <mx:DataGrid id="dgData" x="0" y="20" width="100%" height="100%" dataProvider="{transactionRequest.lastResult.mydata}" itemClick="goto_somewhereelse(event)" alternatingItemColors="[#bfdfff, #ffffff]" > private function goto_somewhereelse(event:ListEvent):void { if(event.rowIndex.valueOf() > 0) { var urlRequest:URLRequest = new URLRequest(); urlRequest.url = "http://www.somewhereelse.com?myid=" + dgData.selectedItem.my_id; flash.net.navigateToURL(urlRequest,"_blank"); } } Hi Michael,
Are you using SWFObject, recently I've traced the IE pop-up to only be occurring while using SWFObject. I've done quite a bit of experimentation on this issue - still no full resolution. Can I say weeks of development time for my company lost on an issue Adobe is pretty much ignoring. But you can follow my results and examples here. http://thesaj.wordpress.com/2008/01/24/the-nightmare-that-is-_blank-flex/ Also, here are three examples embedding the same .swf, demonstrating when the IE pop-up occurs. http://thesaj.wordpress.com/2008/02/12/the-nightmare-that-is-_blank-part-ii-help/ If anyone has some insights, please let us know! After further research, the issue was NOT with SWFObject, but rather caused by a particular parameter entry:
wmode="transparent" causes IE to pop-up block. I have posted a solution on my blog. I have tested it on XP in IE, Firefox, Safari 3, Opera and on OSX in Firefox, Safari 3, Safari 2 http://thesaj.wordpress.com/2008/02/12/the-nightmare-that-is-_blank-part-ii-help/ Exceptions: 1. Requires use of "allowScriptAccess" 2. Fails in IE when wmode property = "transparent" So there we have it, a solution for most instances for most browsers - no thanks to Adobe! Thank you for the help Jason. I have found a work-around based upon your code. I made on modification and now it works in IE and Firefox when wmode is set to window, opaque, or transparent. I modified the openWindow function to:
private function openWindow(my_earl:String, window:String = "_blank", features:String = "") : void { var WINDOW_OPEN_FUNCTION:String = "window.open"; if(getBrowserName() == "Firefox") { ExternalInterface.call(WINDOW_OPEN_FUNCTION, my_earl, window, features); } else { ExternalInterface.call("function setWMWindow() {window.open('" + my_earl + "');}");; } } One issue I ran into is that Safari wasn't responding to:
else { ExternalInterface.call("function setWMWindow() {window.open('" + my_earl + "');}");; } So I was going to place the code just for IE. However, I've discovered that IE is no longer returning browserAgent info to my code. It was last week. And IE 7 does. But IE6 is no longer doing so, I am worried that the new IE6 security update I just ran this morning might have affected something. I've since updated the example:
I successfully tested it on IE6 (PC), Firefox 2 (PC/Mac), Safari 2 (Mac), Safari 3 (Mac/PC), Opera 9 (PC) http://www.easternstorm.net/sassie/example2/example2.html A few caveats, if you are using SWFObject 2.0, make sure you've upgraded to RC2. Also, the wmode parameter must be set to either "opaque" or "transparent" to work in all browsers. *** Not a perfect solution, and a bit cumbersome...but it's finally getting the job done in most cases. (Exception, we still have no solution for when you don't have control over the .swf embed environment and are unable to have allowScriptAccess = "always". Really would be nice to see Adobe step up to the plate on this one. Maybe hopefully come Flex 4 sometime in late 2009 this issue will be resolved.) Thank you Adobe for re-opening this issue!
This is a player bug. It was fixed by the player team for Windows as of their last player 9 update. So, if you have player 9,0,124, navigateToURL should work w/o getting blocked by the popUp blocker. I have verified this. Flash player bug references are #216592 and #215584.
When I tried this on Mac, I found that the bug still existed, so, I have filed a new flash player bug. Reference #225434. I tested in Mac, it worked on the first click but then would be blocked on subsequent. After several tests it seems to just be blocked now.
I had a co-worker test on Firefox in Linux, he too was blocked. Safari 2, Safari 3, and Opera were all fine on Mac. IE6, Firefox, Safari 3 were all fine on Windows XP. So the issue appears to be limited to Firefox on OS X & Linux. (Unix code versions.) Hope that helps! Thank you so much Joan for following up and being diligent with this. :-) This is definitely a significant improvement. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
on (release) { getURL("http://www.badgerbadgerbadger.com", "_blank"); }
works, but
on (press) { getURL("http://www.badgerbadgerbadger.com", "_blank"); }
does not work.
I'll send this bug for internal review to see if there is something we can change (with low impact) on our click event handlers for Button so that simple code like:
<mx:Button click="navigateToURL(new URLRequest('http://www.adobe.com/'), '_blank');" label="open" />
would work in Firefox.