Flash ExternalInterface - Debug checklist
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.
Flash Upload changes in Flash Player 10
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.
Google and Yahoo start indexing SWF's
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.
Flash opens up
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.
Mime types.. when will people learn?
<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>
Flash Uploader on Mac not triggering onComplete event
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.
Leopard first impressions and problems
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:
Library/Preferences/com.apple.Terminal.plist
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.
Flash to support H.264
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.
FLVTool2 broken
To make FLV's coming from flash streaming servers (FCS/FMS/Red5) properly work as a progressive download, it's often required to use a tool to inject 'missing' meta-data.
Up until now I used FLVTool2 for this, but it seems to load the entire FLV into memory (badd!), and now I'm getting nasty errors as well..
ERROR: EOFError
ERROR: /usr/local/lib/site_ruby/1.8/flv/amf_string_buffer.rb:37:in `read'
ERROR: /usr/local/lib/site_ruby/1.8/flv/amf_string_buffer.rb:243:in `read__STRING'
ERROR: /usr/local/lib/site_ruby/1.8/flv/audio_tag.rb:56:in `read_header'
ERROR: /usr/local/lib/site_ruby/1.8/flv/audio_tag.rb:47:in `after_initialize'
ERROR: /usr/local/lib/site_ruby/1.8/flv/tag.rb:56:in `initialize'
ERROR: /usr/local/lib/site_ruby/1.8/flv/stream.rb:447:in `new'
ERROR: /usr/local/lib/site_ruby/1.8/flv/stream.rb:447:in `read_tags'
ERROR: /usr/local/lib/site_ruby/1.8/flv/stream.rb:58:in `initialize'
ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:272:in `new'
ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:272:in `open_stream'
ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:238:in `process_files'
ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:225:in `each'
ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:225:in `process_files'
ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:44:in `execute!'
ERROR: /usr/local/lib/site_ruby/1.8/flvtool2.rb:168:in `execute!'
ERROR: /usr/local/lib/site_ruby/1.8/flvtool2.rb:228
ERROR: /usr/bin/flvtool2:2:in `require'
ERROR: /usr/bin/flvtool2:2
I wanted to try out FLVTool++ anyway, as it seems like a much more scalable solution.. This is how its installed on debian:
Grab the source:
wget "http://rcdn.org:8080/images/4/44/Flvtool%2B%2B.tar.bz2"
Unpack
tar xfvj Flvtool++.tar.bz2
Make sure you have a compiler installed (as root).
apt-get install build-essential
Compiling
make
AArrghh! It doesn't compile :(. This is the error it gave me:
g++ -O2 -c -Wall -D_FILE_OFFSET_BITS=64 flvtool.cpp -o flvtool.o
AMF.h:35: error: invalid pure specifier (only `= 0' is allowed) before ';' token
flvtool.cpp: In function 'int main(int, char**)':
flvtool.cpp:192: warning: too many arguments for format
make: *** [flvtool.o] Error 1
Ok, lets dig into this code a bit.. the errors seems to give a few useful hints..
First thing I did was go to line 35 in AMF.h and change:
virtual std::ostream& operator << (std::ostream& os) const = NULL;
into:
virtual std::ostream& operator << (std::ostream& os) const = 0;
Next, open flvtool.cpp (line 192) and change:
fprintf(stderr, "usage:\n", argv[0]);
Into:
fprintf(stderr, "usage:\n");
Now, for some reason you also need to manually create the bin/ directory in your source directory, after that you can start compiling again.
mkdir bin
make
Success! Your bin/ directory will now contain the flvtool++ binary
./bin/flvtool++
#outputs:
flvtool++ version 1640 2007/05/24 14:39:18
usage:
flvtool++ <input file> <output file> (<start time> <end time>)
flvtool++ -i <input file>
Flash8's ExternalInterface and Internet Explorer
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.
Next page
