bunnyhero dev

…that is to say, I feel I should be blogging it, but I haven’t so far :P

Right now I need to sleep. Perhaps tomorrow I will at least jot down a handful of short notes on it.

I’m going to FITC this year! I’ve thought of going before, especially since I’ve lived in Toronto for the last four years, but I didn’t have the means. I’m pretty excited.

If anyone reading this is going and wants to meet, let me know :D

I recently bought a new cellphone, and it turns out that it supports Flash Lite 1.1. I thought I’d try it out– I’ve developed for cellphones before, using J2ME and BREW, but using Flash for mobile development seems much more appealing.

Alas, Flash Lite 1.x uses a very old form of ActionScript, one that I’d never used before. Things that are missing: Complex objects. User-defined functions. Arrays!!

Maybe I should have picked up a Flash Lite 2 phone! Oh well, it’s still worth looking at…

So I’ve been learning how to play back FLVs with ActionScript. It’s pretty simple, but my first tests weren’t working. I spent some time scratching my head, because my test was a simple modification of the sample code provided in Learning ActionScript 2.0 in Flash.

What was going wrong?

I had taken the sample code and placed it in a method of an ActionScript class. Thus, the variables used in the sample code (e.g. my_nc:NetConnection, my_ns:NetStream) were no longer properties of the movie, but were purely local to the method. When the method completed executing, the variables vanished, which apparently destroyed the connection and stream.

To remedy this, I made the NetConnection and the NetStream properties of the class, so that they would stick around after the method exited.

I had originally thought that keeping around references to the NetConnection and the NetStream would be optional, only necessary if you wanted to refer to them later (like it might be in Java), but I guess not!

Hi5, another social networking site, filters HTML code oddly.

Embeds are allowed (I don’t think they used to be), but if there are any percent signs (%) in the embed‘s attributes, it doesn’t display. Further testing reveals that hi5 seems to strip out any tag that has attributes that contain any URL-encoded entities in it at all!

For example, this perfectly valid code for a link:

<a href="http://www.google.com/search?q=this%2Fthat">search this/that</a>

will not display properly in a hi5 profile. The <a href="..."> tag gets stripped out because of the %2F (an URL-encoded slash “/”).

The downside for me is that pets that have spaces or accented characters in their name will not display on hi5.

I’m guessing that this is their brain-dead way to prevent XSS (cross-site scripting) vulnerabilities as reported here.

It looks like I’ll have to not encode the flashvars at all on hi5. Hope it works properly…

Up until now, I had been making some incorrect assumptions about Adobe Flash Player’s security model.

I had assumed that a SWF could not access anything outside of the domain from which it had been served, in general, without special allowances made by things like crossdomain.xml or System.security.allowDomain().

What I didn’t realize is that these domain restrictions do not apply to the simple use of, say, loadMovie() to load SWFs or JPGs from other domains! It is true that, in general, one SWF cannot read or alter information from another SWF that is loaded from another domain, but simply loading and displaying is fine.

And all this time I had shelved a number of ideas that I thought weren’t possible because of cross-domain issues. Hmmm…!

For reference, here is Adobe’s white paper on the Flash Player 9 security model (PDF) and a white paper on security-related APIs for ActionScript 1.0 and 2.0 (PDF).

I did a very quick test, and it does appear that the way MySpace uses the <object> tag prevents Flash preloaders from appearing as expected in Internet Explorer (tested versions 6 and 7 for Windows). This is the issue that the Flash Satay article reports on. I will attempt to explain it below, as well, and how it applies to MySpace in particular:

In normal situations, the Flash plugin or ActiveX control will start playing a Flash movie as soon as it has loaded the first frame. Flash movies often put up a progress bar that lets the user now how much longer they will have to wait for the movie to finish loading.

On MySpace, Flash movies now only show a generic graphic icon until the entire Flash movie is loaded, instead of starting immediately. This means that the Flash movie has no opportunity to display its own progress bar to indicate loading status (or to just start playing if preloading is not necessary).

Before

This is the way it is expected to look, and how it does work in Firefox (or in IE when embed or IE’s preferred object tag is used).

After

This is the way Flash movies look on MySpace in IE now, before they have finished loading. Obviously, this is much less attractive and gives no feedback to the user. Worse, if a movie does not require a preloader and expects to be able to stream and play its content as it loads, it is unable to do so.

If MySpace wants to rewrite embeds so drastically, I wish they would just use Geoff Stearns’ SWFObject instead. Not only would that solve the preloading problem above, but it would also fix the Eolas “click-to-active” issue that is still present when viewing user-embedded Flash movies on MySpace with IE.

Appendix

Here is the way Internet Explorer “prefers” to see the object tag, and is the way that the Flash IDE by default writes out the object tag. However, I believe it is not W3C-standards-compliant (and is also not compatible with Firefox, Safari, etc). When this form of the object tag is used, Flash preloaders work as expected:

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="320" height="200" id="objectloadingtest" align="middle">
<param name="movie" value="http://bunnyherolabs.com/misc/objectloadingtest.swf" />
...

This is the way MySpace rewrites the object tag, and causes the preload problem. It is (I believe) W3C-standards-compliant.

<object type="application/x-shockwave-flash" data="http://bunnyherolabs.com/misc/objectloadingtest.swf" height="200" width="320" align="middle">
<param name="movie" value="http://bunnyherolabs.com/misc/objectloadingtest.swf" />
...

Mashable reports on MySpace’s new <embed> tag changes. It looked like MySpace was disabling all embed tags, but it seems that they were rolling out this big change. It’s explained better in Chris Bennet’s comment to that post, which I reproduce below (I hope he doesn’t mind):

14. Chris Bennett – January 18, 2007

Before:
MySpace required embed tags to embed Flash content. The preferred method was to embed via the object tag, but that was completely stripped out by MySpace.

This morning:
MySpace began rolling out a change that would block embed tags, but allow object tags for embedded content. This caused some users to report stickers as “not working.”

This morning + n hours:
MySpace finished the change that converted a user’s embed tags to properly formatted object tags and therefore allowed.

Soon, all embedded objects on MySpace will be using object instead of embed. The previous restrictions such as “allownetworking = internal”, “allowScriptAccess = never”, “enableJSURL = false”, and “enableHREF = false” all remain. One new FlashVar I do not recognize is “saveEmbedTags = true” which is probably an internal flag to MySpace.

This is probably part of a larger, more-intelligent Flash filtering solution that would lend itself to a situation where MySpace acts as a gatekeeper to Flash stickers (as discussed).

I wrote about some of MySpace’s previous changes to embedding code in my old tech blog.

I am wondering about the possible technical implications of this change. According to Drew McLennan’s Flash Satay article, the form of the <object> tag that MySpace is using does not stream large Flash movies! To quote the article:

After testing with some largish movies, I noticed something amiss. While every other browser was getting it right, IE/Windows was not streaming—it was waiting for the entire movie to download before playing it. This is fine for small movies, but for anything serious, the lack of streaming is unacceptable.

I haven’t tested this to see if this is still true with the latest versions of IE6 and IE7. If so, this kind of sucks :( Progress bars will not work in such a world, unless everything is “satayed” as described in McLennan’s article.

I guess we shall see what other effects this might have, and what other changes MySpace might make in the near future. If the past is any indication, there will be zero official word from MySpace about this.

I ended up using a different approach to my panel, so I didn’t investigate the problem I was having in my previous post. I’m not running into the issue now, so perhaps it was just something weird with my code.

Here’s what my panel looks like at the moment. The interface is very rough and I’m sure it would make no sense to anyone but myself. It’s a bit of a pain to use, too.

My panel does not monitor the current selection. I tried the test that I linked to in my previous post, and in Flash 8 (at least for me) it causes the IDE to go all wonky: the mouse pointer flickers and changes, and double-clicking on things on the stage doesn’t always work. The symptoms continue even after closing the panel, sometimes! How strange.

Instead, the user has to select the element and then click on the “Get” button. This loads the selection’s information into the panel. “Set” puts the information back into the currently selected element. It’s all rather awkward.

The following two buttons require some explanation. “Memorize Children Pos” takes a snapshot of the positions and orientations of all of the selected element’s “children.” The element’s children are listed in the text area above. Clicking on “Make Children Follow” repositions all of the children of the selected element so that they maintain the same relative positions and orientations as they did when “Memorize” was clicked. Yes, hierarchies of any arbitrary depth are supported, so the children of children (etc) are also moved accordingly.

I am going to continue to use this panel, and perhaps release it, and the source code, at some point. It’s all pretty rough, though, so I am a little hesitant to do so.

Now I’m having trouble with persistent data (set with element.setPersistentData()) being consistently saved when the FLA file is saved. It seems to save correctly with some elements, and not others. It could well be a problem with my code–and for all I know it’s being saved, but it’s not being retrieved properly. I’ll have to try to reduce this down to a reproducible case to see if it really is a Flash bug. Argh.