Dylan Smith

I’ve accepted the fact that I’m a neat freak. So much of a neat freak, in fact, that when my Recycle Bin is empty but the icon still appears to show that there is stuff in there, I empty it again. Well, Windows didn’t like it when I did that…

When trying to purge my already-empty Recycle Bin, I got this disturbing request.

Ok, just what the hell is THAT!? Luckily I didn’t do my usual knee-jerk-click-of-the-OK-button, otherwise I wouldn’t be posting this right now (well, at least not from this computer).

So there you have another undocumented feature of Windows: the ability to send spine-tingling bursts of pure adrenaline through your body at any given moment.

I’ve had my fair share of dealing with IE6 and PNGs. In fact, I’d consider myself an expert on the matter after the number of hours I’ve spent tearing my hair out over it.

The other day I hit an issue I’d encountered before and been able to solve with a simple position:relative (hasLayout) fix. In short, when you apply the AlphaImageLoader to create transparent PNGs in IE6, links within any child nodes of the fixed node may become unclickable and do not respond to hover events – they essentially become pretty coloured text.

This is a fairly well-known bug, and Drew McLellan wrote a great article on the AlphaImageLoader and it’s various quirks on Day 1 of 24 ways to impress your friends.

However, this time, position:relative was set, but I was still having no joy. To make matters worse, it was working in some places, but not others (this specific bit of code was the vertically-scalable body section of a rectangular content module). In some implementations of the module the links worked fine but in others they didn’t. I unsuccessfully tried all manner of logical approaches to isolate the issue. The only bit of insight I could glean was that if I added a large amount of white space to the top of the content, the links eventually started working – it was as if a finite area at the top of the module was becoming “dead space” (although in other modules this wasn’t the case, so it was a confusing as hell).

Finally, I thought it may be related to the “crop” or “scale” method that the AlphaImageLoader uses to render the PNG. I was using “scale”, since the PNG was a background image on a vertically-scalable content area. I increased the dimensions of my PNG from 4px to 500px in height, so that I could use crop instead, and hope my content never got taller than 500px. Instead of fixing the matter, it disabled all links in all implementation of the module on the page. A negative result, but at least some progress.

I deduced that the height of the scaled PNG image seems to influence this bug, so I decided to reduce the originally PNG spline image from 4px to 1px in height, and that fixed it! So impossibly bizarre and random, but there you go.

In summary, if the AlphaImageLoader is breaking your links in IE6, ensure that any scaled PNG images are only 1px in the dimension that you are scaling.

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