By default, browsers with a built-in popup blocker will usually block Flash navigateToURL requests that open in a “_blank” window. For example: navigateToURL(”http://www.google.com”, “_blank”); will generally get blocked. Even if you have a mouse click event to send off the navigateToURL call, it will be blocked.

The good news is that you can get around this behaviour by calling out to JavaScript to handle the request for you. Go ahead and download URLNavigator.as and save it as ~/com/zorked/URLNavigator.as, where ~ is the folder that your FLA or Flex project resides within. In your ActionScript code, import com.zorked.URLNavigator, then call out to method with URLNavigator.ChangePage(”http://www.example.com”, “_blank”); in the mouse event that you’re capturing.

Now, I’ve tested this with a variety of systems, and it works on a lot of them but it’s not foolproof. So far, it works in IE 6, 7, & 8 (beta), Firefox 2 & 3, Opera 9.x, Safari 3, and runs on XP, Vista, and OSX. It may work on additional systems, but my testing is limited. You may also have problems if you embed your SWF in a strange way. It seems to work with most JavaScript embed libraries, but different parameters on the <object> and <embed> could conceivably cause problems.

However, the caveat is this: you CANNOT call this code except within a click mouse event that you’re listening for. Popup blockers will rightfully block an automatic popup, and there is no way around it. If you ask me how to do an auto-popup, I’ll find your house while you’re sleeping; this method is for white-hat developers looking to open a new browser window for good reason.

Additionally, I made an update to the link that was originally saved: Wordpress likes to save files as lowercase names, which Flash had problems with, since the file didn’t match the name of the class. You should be able to download and work with it without having to rename it.

I’m open to suggestions and improvements, and if anyone has access to additional browsers or operating systems that it’s worked for them on, please let me know.

Download: URLNavigator.as

Ok, so we all know how much the Flash Player security model blows. So, because we weren’t in enough pain, Adobe is in the process of making the player even more strict (which is good) by giving you even more mundane tasks to complete if you ever want to do something totally crazy and out there like load SWFs from a subdomain.

You’ve probably already dealt with the crossdomain.xml file, but there are a few changes that you can make to it now, specifically to prohibit crossdomain spoofing if you allow file uploads. You can set the crossdomain file in the root of your folder to be the meta-mega-powerful-nothing-else-counts crossdomain file now.

The really great part about all of this is that regardless of how your set your crossdomain files, Flash Player will NEVER let you load a SWF from another domain and operate on it without the Security.allowDomain() set on the loaded SWF. It doesn’t matter if your crossdomain is as loose as a college cheerleader, or if you do the meta-crossdomain file, or set a crossdomain on both the loading and loaded domain. It doesn’t matter. The only way to get around this is to create a proxy SWF on the domain of the loaded site and pass in the URL that’s on the same domain as the proxy that you actually want to load.

More info on the Flash Player 9 Security Updates.

There are a lot of problems with the transparent windowing mode (or wmode, as many are familiar with it) in the Flash browser plugin. It’s especially bad in Firefox’s implementation, as it will no longer dispatch Event.RENDER, which the CS3 component architecture is dependent on. Without a RENDER call, the components don’t show up, although they will take text input. The only way you can tell that they’re alive is that they FocusRectangle will come up if you click on it.

Now, if you legitimately need the transparency of the windowing mode because you’re popping a huge purple gorilla over the normal page, you’re pretty much stuck, unless you want to hack the UIComponent class to use an ENTER_FRAME event instead (which did not work for me). However, most people are actually looking to be able to z-index the Flash movie, in which case you can just use the “opaque” attribute value instead of “transparent”.

Remember, this is a single param of the object, like <param name="wmode" value="opaque" /> instead of <param name="wmode" value="transparent" />

If you’re interested in what’s happening behind the scenes, here’s the deal: normally whenever a browser lets a plugin lay itself on the screen, it’s actually doing a managed window outside of the actual page that you’re browsing; in short, it’s not part of the actual layout. So, instead of being on the screen, it’s in a layer above everything else except for other plugins. When you scroll the page, the browser scrolls the plugin too. Normally, you don’t notice this because it’s pretty much instantaneous. The only time you notice is when you have a dropdown menu that always falls behind the plugin, for example.

When you put the wmode (window mode for short, remember) parameter on the object/plugin, it’s now telling the browser to interlay the plugin with the rest of the elements that are in the page. In fact, it actually is one of the elements of the page, and is now z-indexable.

One minor problem with this approach is that performance is slightly slower, regardless of whether you chose transparent or opaque mode (although transparent is even slower). Most users will not notice, but be aware of it if you’re doing timer and sound synced animations.

Here’s a nice gotcha I found a while back when trying to run a filter on some XML data. If you write an attribute filter inside of a switch statement, the query will return null when you assign it to the XMLList variable. If you trace out the query instead of assigning it, it works fine.


switch (anything) {
case "testcase":
var xlData:XMLList = xmlData.Books.Book.(@author == 'Dickens');
break;
}

The above code will fail; apparently the scoping inside of switch statements is broken. There’s a bug report filed already, but it would be nice to see a fix for this.

Flash Player 9’s been out since June of 2006, and in less than a year it’s jumped to 81-84% penetration, which is great news. I hope that Adobe can continue to release the player versions ahead of time and keep everything up-to-date with the autoupdaters so that when the authoring tools come around, plenty of people are actually using the player at launch date.

Here are the stats.