Legacy Flash content? Need to move to HTML5 but still support the old Flash files? With Clickspace TV, I’ve been there, and I’ve gladly moved on, but Flash hung on for over a year after we stopped authoring new content in it. While it would be better to ditch those .swf files entirely, that may be impossible, so here’s how you work around it.
Google has been pushing using their Chromebox and Chromebook products to serve ‘kiosk’ apps – Chrome Extensions that load without a Google user attached to it. You can’t load Flash into a kiosk app, period. You need to be logged in to give Flash special permissions, but the kiosk apps run without a user, so it’s a catch 22. A very time-consuming and likely useless work around – uninstall ChromeOS, and install Ubuntu instead.
For a user to install this Chrome Extension on their own, they’ll need to go fiddle with some security settings for it to work. Don’t expect too many to go through with it.
Also, the steps needed to make this work give Flash a lot more permissions. Chrome’s security is good, but Flash is a weak link. User beware.
The Easy Part
First up, you need to let the Flash player know that you’re planning on using it outside of the normal usage. This has to be done for each install of the extension.
- Head over to the Flash Settings Manager, Global Security Settings and add chrome-extension:// as a ‘trusted location’.
- NOTE – I never tested this, but you may want to refine that to include the exact uri of your extension(s).
- You may also want to go to the Global Storage Settings panel icon and crank up the allowed storage per site – since you’re using a single Chrome Extension to serve all of your Flash content, the 100kb default will likely run out very quickly.
- Next, head to chrome://plugins/ (Chrome won’t let me link to that, sorry). Each plugin has a checkbox that says “Always allowed to run”. Flash needs that checked to load in a Chrome Extension
The Hard Part
Flash content will now load in your Chrome Extension – a quick way to test is to embed an iframe to a page running Flash (like speedtest.net). But your Flash content may need some rewriting. I ran into a larger list of todos than most, because I had an Adobe AIR wrapper running individual swfs. My list included:
- No more access to the local filesystem – everything had to be rewritten to download at runtime
- Downloading at runtime in Flash would often pull files from the cache instead of the web, so content would get out of date quickly
- I had to write an entire communication layer (using External Interface) so my old Flash content could let my app know what it was up to, and vise-versa
- My Flash content used to stream videos from the hard drive, but was now streaming them from the web/cache. Not sustainable, so I had to create a way to let the Chrome Extension know to download a video, save it locally, and play it back underneath a now transparent Flash layer. With more communication to make it all work
- Various permissions challenges – files that Flash was getting itself now had to be routed through the extension and fed back in as Strings.
- Where Flash uses a crossdomain.xml file to dictate rules for pulling content from a foreign domain, the HTML standard is CORS headers instead. So not a problem with Flash, but new problem when moving content from Flash to the Chrome Extension.
- Security and loading restrictions had to be eased – in AS3, that means using the flash.system.Security class to allow a laundry list of domains
- The Chrome Extension would not load external swf files. A Flash loader had to be written and embedded in the extensions itself. The swf doing all of the loading of other swfs had to download them using a URLLoader, then extract the binary using a Loader, then parse the binary as a MovieClip before I could use it.
Nope. If you can avoid supporting Flash, you should. If it’s unavoidable, you’ll spend a lot of time learning more about Flash, a technology you’re trying to kill off so you don’t have to spend any time on it. It’s a losing proposition, even if it’s a necessary one.