Dylan Smith

I was asked to fix an old piece of AS2 work today (meh). The piece in question featured a custom mouse cursor, and the client wanted the custom cursor to disappear when the actual mouse cursor left the Flash movie, rather than having it stop on the edge of the stage looking lost. Fair enough. AS3 has the awesome new MOUSE_LEAVE event for such things, but this was AS2.

I looked for a few quick solutions online and all of them seemed like too much work, in particular a solution that created JavaScript listeners with ExternalInterface to monitor the mouse position on the containing document. That is a bridge too far for me I’m afraid.

In AS2 you can monitor the rollOver and rollOut events of a MovieClip as long as the mouse doesn’t leave the stage. For example, if a movieclip is the same size as the stage and positioned at 0,0 the rollOut event doesn’t fire because the mouse leaves the stage at the same instant that it leaves the movieclip. However, if the movieclip was slightly smaller than the stage, the rollOut event would still fire because the mouse cursor would still be within the bounds of the stage when it left that movieclip.

So, my solution is to place a transparent movieclip over the movie, with a very slight border around it (say, 2 pixels). That gives Flash enough time to relase that the mouse is just about to leave the stage, before it actually does. Here is the code:

// create the mouse detection movieclip
var mouseLeave_mc:MovieClip = _root.createEmptyMovieClip('mouseLeave_mc', 9999);
var border:Number = 2;
mouseLeave_mc.beginFill(0x000000, 0);
mouseLeave_mc.moveTo(bdr, bdr);
mouseLeave_mc.lineTo(Stage.width - bdr, bdr);
mouseLeave_mc.lineTo(Stage.width - bdr, Stage.height - bdr);
mouseLeave_mc.lineTo(bdr, Stage.height - bdr);
mouseLeave_mc.lineTo(bdr, bdr);
mouseLeave_mc.endFill();

// set event listeners
mouseLeave_mc.onRollOut = Delegate.create(this, function() {
	// the mouse is about to leave the stage
})
mouseLeave_mc.onRollOver = Delegate.create(this, function() {
	// the mouse is about to enter the stage
})

I hope you find this post before you spend days scratching your head trying to debug tweening code that seems perfect (like we did).

We recently built a Flash piece that required 6 product shots to tween into position on the stage. No biggie right? Well, until for some reason known only to God, the tweens would inexplicably stop at random points along their path. They didn’t fire a Tween.MOTION_STOP event, they did not pass “Go”, and they did not collect $200.

Well, thanks to this blog post, we think that it’s a bug in the AS3 garbage collector that destroys the tweens while they are still in motion. That sucks pretty hard. I found further evidence in the comments on Adobe’s official Tween class documentation page. That’ll learn us to RTFM in the future!

The weirdest part was that it only happened in Firefox for us, and only on the first page load. If you refreshed the page, it seems to work fine. I guess the Flash Player must interact with the browser in some way when dealing with memory management, and hence the issue appears to be browser specific.

We’re moving to tweenlite or tweener until Adobe sorts this out.

Today at work one of our developers came to me and mentioned that he’d encountered a real head-scratcher of a bug: all of a sudden, the sIFR headlines on the site he was working on all had green backgrounds, and the drop-down menus on the site were now appearing underneath all Flash elements, sIFR or otherwise. This was only happening on Firefox 2.0.0.11, and on one other workstation as well, so it was not a localised/environmental bug.

wmode

Now, when someone mentions Flash elements breaking through layered DIVs, my first thought is “wmode”: the Flash embed setting that controls the “window mode” of an embedded Flash asset. “wmode=opaque” will instruct the Flash Player to use the background colour of the SWF, while “wmode=transparent” will instruct the Flash Player to make the background of the SWF transparent, so that the page below it shows through.

wmode also has implications for how a Flash asset interacts with other elements that may be placed on top of it. If you do not set wmode in your embed code, a Flash movie will always play above all other elements on the page. If you set wmode to be either transparent or opaque, elements will be able to hover above a Flash asset quite happily (Opera historically had some issues in this area, which are thankfully solved in the latest releases). See Adobe’s Technote on this issue.

wmode could also feasibly have been responsible for the green backgrounds in sIFR: I’m not sure why the colour would be green, but clearly the Flash was not rendering with a transparent background as is the default with sIFR, so something was definitely up.

We checked a few other workstations, all running the same version of Firefox, and none could replicate the issue. Since the codebase worked fine on most workstations, we could only deduce that there was some corruption or issue with either his version of Firefox, or his version of the Flash plugin, or an interoperability issue when the two are working together.

Culprit: the FireShot Add-On

After some Googling, I happened upon a useful post at Trevor Davis’ blog, discussing the green background issue with sIFR. It appears that many people started experiencing this issue – and other issues related to wmode – after installing or upgrading to FireShot 0.31. This is more about this in a discussion at the Firefox Add-Ons site.

So, it appears that FireShot 0.31 modifies a configuration setting called “general.useragent.extra.fireshot”, which appears to add some spam about FireShot into your browser’s user-agent string. What was most interesting was that the actual value of this setting included a URL, in the format “http://domain-name/”, which I believe might be the cause of the bug.

User-Agent Strings

I’m not sure if there is some globally-recognised standard for the formatting of user-agent strings, but Mozilla seems to adhere to a specification. A quick read will reveal something that seems intuitive to someone who has even seen a user-agent string: “/” and “:” characters are special character used to delimit or indicate certain data within the string.

Therefore, if a URL in the format “http://domain-name/” was appended to the Firefox user-agent, the “://” part of the string would quite likely invalidate the user-agent string, and cause issues with the way in which Firefox interprets it. How this in turn effects the way in which wmode is interpreted is unfortunately beyond me.

Undoubtedly Firefox should better sanitise the configuration values that may be included in the user-agent string. However, I also think that it’s quite cheeky for FireShot to try to include the URL of their website in the user-agent string as some sort of desperate publicity stunt.

The Solution

However, if you encounter this issue, it can be easily solved:

1. Open up a new Firefox tab, and navigate to “about:config”. This will open the Firefox configuration registry.
2. Type “general.useragent.extra” in the “Filter” box.
3. Right-click on the “general.useragent.extra.fireshot” entry, and choose “reset” to clear it’s value
4. Repeat the step above for any other add-ons who may be using your user-agent string as free advertising.
5. Restart your browser, and the issue should be resolved