Het Bijstere Spoor

Flash' ExternalInterface api allows you to communicate between Javascript and Actionscript. A very useful tool, and we've used it quite a few times. Often times it just doesn't work though, and it can be difficult to get to the root of the issue. This is a list of things you should be looking out for if ExternalInterface does not work for you:

Give your <object> tag an id

In order to call your flash application, your <object> tag needs to have an id attribute. Make sure this attribute is unique.

The id cannot collide with items in the document object

Internet Explorer will add any element with an id to the document object. So if you were to, say, give your object the name 'window', 'getElementById' or anything to that respect EI will not work.

The object cannot be embedded in a <form> tag

EI will not work in IE if the object sits in a <form>-tag. For some reasons IE will treat any element within a form slightly different.

Don't use 'play' or 'stop' for method names

Another IE issue. play and stop are somehow reserved for IE. This only applies to actionscript functions you're calling from javascript.

Check your domain names

If your swf is loaded from a different domain as your html document, you need to make sure you add this domain through flash.system.Security.allowDomain. In our case it was fine to just add Security.allowDomain('*').

If all else fails, know how to debug.

Much like with XMLHTTPRequest, errors will not show up in Firebug by default, but you can trace everything if you check everything in the Console-tab-submenu. This will also allow you to see some of the automatically generated javascript Flash produces.

Most of the above issues are in IE, but thankfully Microsoft's script debugger will actually catch these (rather cryptic) errors, which might help you find your problem.

We've run into every single one of these issues, if you have any others like this, please comment :). I figured it would be helpful to have one single source of documentation.

This has been covered on other sites even when FP10 was still beta, but sadly I've just ran into this one right now.

Flash Player 10 no longer allows uploads to be invoked from within javascript, and requires an actual mouseclick or buttonpress event from within flash. For the people using tools like swfupload or the (old version of-) YUI uploader, this is bad news, as these tools will simply break.

The fix was made as a security measure against phishing-type attacks, and this has been the behaviour in browsers for as long as I can remember, so if its any consolidation.. it's a good thing really.

The Flash Blog mentions:

Similarly, another possibility is to overlay a transparent SWF button over the HTML content so that again, the user clicking happens in Flash and not in HTML.

Which is actually kind of funny, in a time where 'Clickjacking' is big news, and I would also strongly discourage such attempts to make sure you have a solution that still works in 2009. I'd like to see an example of this, just to test if noscript's clickjacking protection works.

The only real options out there are to simply switch back to good old html uploaders, or do your uploader interface entirely in flash. We'll probably be implementing the former in the short term to work on the latter down the road. The updated version of the YUI uploader also takes the flash approach.

Via: Theo Hultberg.

An odd story caught my attention recently, and I've been meaning to put my thoughts down.

I'm often asked the question about indexing flash content recently, and the recent announcement by google only increased the stir.

It's odd, because even Adobe employees seem completely clueless about what it means, and the implications.

Quote from Ryan Steward:

So what does that mean? We are giving a special, search-engine optimized Flash Player to Yahoo and Google which is going to help them crawl through every bit of your SWF file. This Flash Player will act just like a person would in some cases. It will click on your buttons, it will move through the states of your application, get data from the server when your application normally would, and it will capture all of the text and data that you’ve got inside of your Flash-based application. We’ve basically provided a very powerful looking glass into SWF files so Google and Yahoo can pull out meaningful information.

Is in sharp contrast with what google is saying:

We currently do not attach content from external resources that are loaded by your Flash files. If your Flash file loads an HTML file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file.

So essentially, google will index your SWF, but not the actual content it loads. Most modern Flash Apps don't hardcode any textual content these days, and will likely load most of their data from the servers. Most importantly, I feel the SWF should not be indexed at all. SWF is middleware, it is responsible for delivering content to the user, it (should not) be the actual content itself, for any serious web application.

One more gem from the Google blogposting:

That said, you should be aware that Google is now able to see the text that appears to visitors of your website. If you prefer Google to ignore your less informative content, such as a "copyright" or "loading" message, consider replacing the text within an image, which will make it effectively invisible to us.

So where is this coming from?

My guess is one argument between picking HTML vs. Flash to deliver your content, it could be said that a Flash is not SEO-friendly. Getting this message out allows pro-flash people to fight back a little. It definitely feels that this whole announcement has little to do with the technology, but much more with putting the Flash-brand in a better light.

How would one actually make SWF's SEO-friendly?

Just don't. Make sure the content is available on the web in an alternative format. Often your flash content is stored in a database (or an XML file for smaller sites). Pick up your favorite server-side scripting language, and make sure the content is also available in an indexable format. Using fancy CSS and Javascript usage you can make sure the content is replaced by the Flash content when a regular user visits.

If you do this, all the normal SEO rules are applied. As a side effect, the user also benefits from this as your content degrades nicely for older or for example mobile browsers, people with disabilities and you name it. The sole reason for this is that search engines are actually try to find 'quality content' based on your search query.

Last but not least, XHTML is a form of XML. If you use XHTML as a datasource for your content, search engines can also access it directly.

Pretty big news coming from Adobe today, as they opened up the specification for the SWF and the FLV / F4V formats.

This basically opens the door to play banner ads and intro's properly in alternative players, such as Gnash and it should also help development of flash video streaming projects such as red5.

Gnash actually has a fair support for the SWF format, but because of the legal restrictions around the spec they were never allowed to read the spec. Now they should be able to implement the full SWF format easily.

I've been following a lot of adobe/macromedia blogs over the years through MXNA (currently down) and attended some flash conferences, and about half of the flash developers always seem to use the argument 'if there's other flash players out there, incompatibilities will arise', basically favouring a closed spec. I always had a feeling this was strongly influenced by Adobe/MM propaganda, so it will be interesting to see if the majority of the community changes their opinion after this news.

As for my opinion, I'm biased. The news is great for end-users, for sure. Currently the flash player is said to be installed on 98% of all computers hooked up to the net, which is higher than the market share of IE, or Windows. This makes it the best possible platform to target for security holes. It also removes the vendor-lock in and it can improve competition and therefore innovation. I don't like it, because SWF is a messy binary format and I rather see a prettier text-based formats such as HTML 5, SVG and Javascript 2 finished and gain adoption.

<rant>

HTTP has an incredible useful feature to supply the Content-Type HTTP header for any url. This allows HTTP clients to easily figure out what type of data they're getting.

Over and over again I see clients, not doing this and making assumptions based on the url. The extension of all things! This is some artifact inherited from ms-dos, and passed on to different operation systems when GUI's became popular.

Two clear examples I have today (and I'm sure many people will have examples like this)

• Flash's VideoPlayer component. If there's no extension in the url, it will assume its some kind of xml file.
• iTunes podcasts.. Files have to end with a known extension for iTunes to pick it up as a video or audio file. Even though the Mime type has to be specified in both the RSS feed and the HTTP Header!

WTF?

</rant>

We have had a whole bunch of issues with the Flash 8 uploader on OS/X in the past. Now its completely broken on leopard, but before we weren't able to do multi-file uploads because the 'onComplete' event wasn't triggered from within flash.

We've been using a (modified) version of SWFUpload and also our Flash applications have had this issue..

Today I read on The Joy of Flex-blog that there's actually a really simple solution to this problem. Have your PHP (or other server-side) simply return some data. Our upload-endpoint normally always returned nothing at all, because it seemed unnecessary, but returning a small body in your HTTP response fixes the issue!

As you can tell, I'm excited.

I don't want to sound like I'm complaining too much, because I actually really like the new version of os/x. I wanted to cover a bunch of problems so people might know its not just them.

First, my personal favourite improvements.

The terminal

I'm especially happy that some time was spent improving the terminal application. Half my day I spend in that application, and any small improvement is welcome there. The most important being tabs (yessss) and an always running ssh-agent (which integrates with the keychain).

I ran across a bunch of problems as well ..

Flash upload stops working

Since we deal at FileMobile a lot with uploads of large/huge files.. we use a Flash uploader. It completely stopped working in leopard and from what I hear an update of the flashplayer is in the works.

Windows magically disappear using spaces

Spaces is a nice tool and i feel like it could help productivity.. but when you're switching between a few spaces sometimes windows get completely lost and the applications need a restart to re-appear.

Terminal won't change the background color

I'm fairly sure this has to do with the fact that I used a background image for my terminal in tiger; which is a feature that has been removed in leopard. I really dislike the default black-on-white, but I couldn't change my background color anymore. The solution for this was to simply remove:

From my home directory.

My key-bindings for page-up and page-down are lost in the Terminal.

I haven't felt like trying this yet, but I assume I simply have to follow my previous steps, if not.. I'll post about it later..

Airport up and down

Not sure if this is the OS or the airport, but its been shaky.. Hope this gets improved with an update of some sort.

Jed Wood pointed me to an article from one of the engineers of the flash player, stating Flash is going to start supporting H.264 video (in essence, mpeg4). So yes, this means you can play MOVs in flash, if they are using H.264 and the AAC audio codec.

The signs were already there, as ON2 announced H.264 support in their flix product line, but now it's official.

This pretty much means the death of the proprietary FLV format, which was both from a business and a technical standpoint inferior. Before flash supported a subset of H.263 (a.k.a. Sorenson Spark) and VP6. Although converters for H.263 have been available for a long time, the actual FLV format (wrapper) and the much better VP6 codec remained 'officially' inaccessible. MPEG4 is still a patented technology, but at least there is now a wide range of choices and software to produce this.

The new flash media server, which can be used for video (up and down)streaming will also start supporting this. It's not clear to me if the proprietary Nellymoser codec, which is used for recording audio from the flashplayer will also be replaced.

I wonder what this means for ON2, who just lost their single key selling point for their Flix software. They never had transparent pricing for their (buggy) Flix engine, so now they will lose the fact that they were the only way to go if you wanted to convert video using a modern codec.

This is for the googlers who might run into the same problem as me..

If you try to use ExternalInterface, your flash object should not be a in a html <form> tag.. If that is the case, ExternalInterface will not work at all!

I had a hard time figuring this out, until I stumbled upon a comment in the LiveDocs.

I heard a few times in the past about SWFUpload and recently I decided to try it out..

Basically SWFUpload is a 0x0 pixel swf that allows you to leverage Flash 8's upload mechanism through html/javascript. Not only can you let your users select multiple files to upload, it also allows you to catch the progress nicely, without a combination of nasty hacks with javascript, hidden frames and server-side callbacks.. It it distributed under the very permissive MIT license.

However, the integration went pretty bad.. SWFUpload is a very complete package and includes a big javascript wrapper, a bunch of examples and SWFObject, which is used to embed the object in the html using javascript and examples. For some reason it didn't work for me all, I assume there was probably some collision with my existing javascript.. and I don't really like SWFObject, as it has to my opinion overkill written all over it..

So, I peaked into the javascript, only to find out that just using the swf you have a lot of power already, you can specify your javascript callback functions straight from though the flashvars.. Neat! The flashvars look something like this:

Very easy to use.. The only thing I really miss is the fact that selecting files and uploading is a combined step.. Not really handy in terms of usability..

My feature requests:

1. Have a separate method for selecting files before upload.
2. Allow the ability to replace the file upload list, but also append to the list.
3. Have the callbacks return index numbers for the files.. Right now the only unique property you get is the filename, and there could be situations where 2 files with the same name are uploaded (rare, but still..).
4. Implement a method for canceling the upload progress.
5. Implement a method to remove a file from the upload queue.

The other problem I ran into using flash uploads are http cookie bugs.. I covered that in my last post.