Mark Ledford's Blog

It’s pretty frustrating when you attempt to do something as commonplace as add a custom preloader to a Flex App and and you end up debugging for hours because something went pear shaped for no apparent reason at all. No matter what I did the preloader would not show up until the app was loaded and it moved to the initialization sequence of the preload. During times like this Adobe’s public bug database is a godsend.

[SDK-14162] [Flash Player] Preloader not showing up when we add deeplinking urls
[FP-2332] Named Anchors in URL prevent SWF from being streamed in

Turns out there is a pretty significant Flash Player feature (read bug) that will foobar preloaders for Flex apps (and probably even regular Actionscript projects) if they contain an anchor tag. As described and as I’ve reproduced, this issue would effect most major Flex apps and Flash sites as most use deep linking techniques with hash tags like with SWFAddress.

Alex Harui explains the issue in the latter Jira like so:

This problem is due to a feature in the Flash Player that allows deep-linking in Flash Authoring SWFs. If you label frames on the timeline in the SWF, you can jump to them by putting hash fragments on the URL.

This feature is, of course, completely useless for Flex deep-linking as Flex apps only have two frames and there’s no way to compute what label to use on the frame.

This bug will remain NAB for now. We have made a request for a way to opt out of this feature in future players but it may not happen any time soon.

Technically it seams what happens in the swf will try to skip ahead to a non existent frame label causing it to prevent your swf from properly streaming.  The current fix is to use BrowserManagerShim.as a class provided in the first Jira that just loads your swf and takes the hash tag issue itself.