Recommendation: Disable Invisible Flash

To this day, I still question a small change we made back in ClickToFlash 1.4: enabling loading of invisible flash by default.

"Invisible" Flash are small flash views that are ≤ 8px × 8px. We choose 8px based on numerous bug reports about sound/music sites not working with ClickToFlash, and discovered most of these sites utilize Javascript-controlled faceless players as a sort of an HTML Sound API in an otherwise standards-based site architecture.

Enabling invisible flash loading by default was definitely the right call, especially as ClickToFlash moves ever-more-mainstream. It’s confusing when a site seems broken and most users don’t discover the Safari > ClickToFlash > Load Invisible Flash for Frontmost Page menu item to “fix” it.

Most folks object to Flash because of its distraction, crashes and CPU load. But invisible Flash views aren’t visually distracting, and they don’t seem to suck up as much CPU as visible Flash views or crash as much.

But folks who read this blog are more technically savvy than the normal ClickToFlash user, and I recommend you join me in disabling automatic loading:

ClickToFlash Preferences

I recommend this for performance, security and privacy reasons (primarily Flash cookies, which I suppose I should write up as well).

I think ideally ClickToFlash should ship with invisible flash loading off by default and offer an asynchronous Growl-style notification system when a page is loaded that hosts an invisible Flash view.

However the UI for that is tricky, especially since WebKit is used in so many more applications than just Safari.

It’s much more straight-forward to offer such a notification system in a Chrome/Chromium Extension, since that browser offers an explicit API and UI for such async notifications. So I think such notifications will appear there first.

clicktoflash Nov 27 2009