The nightmare that is “_blank” & Flex

UPDATE: I believe the example will work in all common browsers (Firefox, Safari, IE, Opera) on both PC & Mac platforms.

NOTE – If you’re using SWFObject 2.0, you need to upgrade to RC2!


I created a bug tracker listing for this issue a while back at It was closed – I believe improperly so.

Please consider visiting the listing for this issue. While you cannot vote because it’s been closed. You can comment, and you can add the listing to those items you are watching.

UPDATE: I revised the code to handle for Safari 2 (sort of). Essentialy, I was not getting a response from Safari 2 on the browserAgent request. My conditional was failing unexpectedly.I’ve revised the code, and confirmed that it now reaches the “Undefined” option. Which uses the standard navigateToURL(). And should work in Safari 2.Too those readers who still have access to Safari 2, if you could confirm that it is now working for you – much appreciated.- The Saj

PS – Special thanks to multi-Safari and to Subtlegradient for the fix that re-enables multi-safari. Which allowed me to install Safari 2 on my Mac for testing purposes. (Why Apple & Microsoft fail to see the need for us developers to run multiple browsers we will never know.)

One of the very first headaches I encountered with Flex was when I tried to pop-out a link using “_blank”. ActionScript 2.0 used _getURL(), in ActionScript 3.0 this was changed to navigateToURL().Imagine my horror when after uploading my new Flex app live to discover that clicking was caught by Firefox’s pop-up. The old _getURL() worked fine, but I really didn’t want to go back and re-write my app in Flash / AS 2.0A little research revealed a work-a-round using the externalInterface command to call out to the browser and pop open the window using the command.However, I would more recently discover all of my Flex applications failing to work in the new Safari 3.0, Safari 2.0 works with the externalInterface work-a-round but for whatever reason Safari 3.0 does not. Further research led to another work-a-round to check the browser brand then use conditional if/else logic to enable the application to either use the externalInterface() method if Firefox or the navigateToURL() method if another browser.Now for my applications I have made these into two separate re-usable classes. However, so as not to confuse those new to Flex and still unfamiliar with classes, I have made a simple and stupid example that incorporates all of the code in one MXML file. Hopefully this example will help you if you’ve encountered this issue:
(right-click to view source)

– The Saj

8 Responses to “The nightmare that is “_blank” & Flex”

  1. 1 Jim January 24, 2008 at 11:27 pm

    Whenever you need to rely on the browser to do something – even something as basic as opening a new window – you’re asking for trouble. This is one of the reasons I’m excited about AIR; it gives us a way to deploy Web-enabled apps that are free of the browser. Thanks for posting this code – I’m sure a lot of people will find it helpful.

  2. 2 Jason The Saj January 24, 2008 at 11:33 pm

    Quite true….

    Especially annoying when something worked in an old version of a browser but fails in a new version.

  3. 3 Gareth January 25, 2008 at 8:07 am

    I just tried the sample page (XP, Firefox and it blocked the pop up as well.

  4. 4 thesaj January 25, 2008 at 8:40 am

    Strange, I’ve tested the example on all of the following successfully:

    > Firefox 2 on OS X (
    > Safari 3 on OS X

    > IE 6.0 on XP
    > Firefox 2 on XP (
    > Safari 3 on XP
    > Opera 9.25 on XP

    All six instances popped up new windows and/or tabs as specified. I am wondering if you have a security setting added or a 3rd party pop-up blocker plug-in.

    I’ll put this out and see if anyone else is running into the problem still on Firefox. I’ve also modified the example to output the browser agent info that’s captured during the click.

    Give it a try and send me the info if you would and we can see if anything stands out to us.

    This is what I receive currently…

    “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/”

  5. 5 Jeff Houser January 25, 2008 at 4:50 pm


    I wouldn’t say that AIR is free of the browser. It’s just that you have only have to build for one browser (The embedded version of Webkit ).

    There is some relief in that; although I’m not sure if “Windows” means the same thing when comparing the context of AIR to a web browser.

  6. 6 Mike January 31, 2008 at 11:06 am

    I recently did some work involving some the same type of research. I had found that Safari 2.x does not support inline javascript like this. So, in your example, browserAgent will be null because the js does not get executed. Instead, you would have to use a typical“myFunc”), where myFunc is declared in the wrapper, for older Safari browsers. I am using 2.0.4 OSX

    I am curious as to why you are creating the js function inside your ExternalInterface call rather than making a call to a function that is declared in the wrapper.

    Good Example!

  7. 7 thesaj January 31, 2008 at 3:20 pm

    Currently, I am unable to test on Safari 2 (one of the few OS’s along with IE 7 that I am not currently set up to test).

    I know the old external interface work-a-round I used did work on Safari 2. So I probably need to extract “version” number of the browser as well. Then amend the conditional code correspondingly. In my old code I was only testing and conditioning for Firefox. I’ll have to try to get Safari 2 installed on my machine and evaluate more thoroughly. Thank you!

    As to why I am creating the JS function inside the ExternalInterface rather than in the wrapper (I presume you are referring to the embed code in the html). I am doing this because I don’t always have control of the embed code. So creating a Javascript function in the html template is not always an option. Second, it reduces the number of templates.

    In fact, recently I’ve been experimenting with similar code design to pop up a new window and send variables via “post” rather than “get” method.

  8. 8 feather April 24, 2008 at 5:25 pm

    The implementation above works for buttons but unfortunately doesn’t prevent FF from blocking an HTML style link in a text area. I’m assuming that FF doesn’t generate a click event for HTML links and so cannot recognize that the URL request is user generated, blocking it even if it’s called through the external interface.

    I’d love to know if anyone has come up with a work-around for this issue.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

January 2008

Awesome Developer Conferences

Nxtbook MediaFormer Employer - Great Company

The Saj... "Dark Lord of the SWF"