I just dropped ClickToFlash 1.5.4 which fixes YouTube’s “Old Flash? Go upgrade!” message in the 1.5 branch (it’s been long-fixed in the 1.6 branch).
With this release, both 1.5.4 and 1.6b8 now advertise their presence (and version) via Javascript. This is mostly to assist Mark Pilgram’s Flash Block Detector project.
To use ClickToFlash’s new feature, call the GetVariable() method on the plugin object with a '$ClickToFlashVersion' key, like so:
document.getElementById('myFlashObject').GetVariable('$ClickToFlashVersion'));
If you get back null from the call, that means you’re talking to the Flash plugin. Since it doesn’t understand the $ClickToFlashVersion key, it just returns nothing.
However, if you get back a string, it should be ClickToFlash’s version number (such as '1.5.4' or '1.6b8') and it indicates the user hasn’t clicked the flash box yet.
Tip: if you’re testing locally, GetVariable('$ClickToFlashVersion') will always return null since local files are whitelisted by default.
[Hi TUAW readers, as I mentioned in a comment: ClickToFlash version 1.5.4 is about ready to go out, which rolls in 1.6b7’s YouTube fix. It will be available via the normal Sparkle upgrade channel, so it’s cool if you just want to wait for the auto-update.]
If you want a great concrete example of how open source rocks, look no further than ClickToFlash’s “Old Flash? Go upgrade!” message with the new YouTube makeover Lighthouse ticket.
ndfred filed an awesome bug report. I started reversing YouTube’s obfuscated JavaScript, but was beaten to the punch by Justin, ssp and lapcat.
Between getting sick multiple times while traveling to Paris+London+Atlanta, writing slides, presenting at NSConf and blowing out my back, the last six weeks have been hell on my productivity.
It heartens me that even though I stalled out, this loose team of four guys dissected the problem and coded a solution.
I’m honored to bundle up their work and push out this update. I’m really proud of you guys, pushing the project forward even when I can’t.
I wrote up a proposal to distribute ClickToFlash as a System Preferences.app .prefPane.
Comments invited.
Scott Morrison, author of Mail Act-On, forwarded me this interesting screenshot:
It’s apparently ClickToFlash 1.5.3’s built-in Sparkle offering the latest beta of Mail Act-On.
Confusing.
My hunch is that is that in this scenario, ClickToFlash started using Mail Act-On’s appcast instead of its own.
Mac OS X’s impressively-broken framework-leakage is the primary reason we (mostly @simX) have moved Sparkle into its own updater-helper in version 1.6 of ClickToFlash.
Sadly, moving moving Sparkle into its own helper is merely a band-aid: it reduces the probability of class collision/leakage, but doesn’t solve Mac OS X’s underlying issue.
Perhaps we’ll see something approaching a real solution circa 10.7.
[NEW] Explicit Vimeo support: watch and download H.264 versions of Vimeo videos without loading their Flash player. (Sven-S. Porst)
[NEW] Poster frame of YouTube and Vimeo videos are loaded in lieu of the default gray-gradient background when H.264 support is enabled. (Sven-S. Porst)
[NEW] Whitelist now applies to entire URL rather than host. This allows things like whitelisting
google.com/analyticswithout whitelisting all ofgoogle.com. ticket 361 (Sven-S. Porst)[NEW] Glossy effect on video poster frame. (Sven-S. Porst)
[CHANGE] Solid, more opaque background for contextual-menu gear so it’s visible against a variety of video poster frames. (Sven-S. Porst)
[CHANGE] Drawing and mouse-handling code migrated to NSButtons to pave the way towards accessibility. (Sven-S. Porst)
[CHANGE] Improve handling of embedded YouTube’s use of
swfArgs/SWF_ARGSs. (Sven-S. Porst)[FIX] Improve “Larger Size” download link text. ticket 346 (Sven-S. Porst)
[FIX] Explicitly cancel HTTP HEAD requests to work-around a 10.5 bug that downloads the entire file. http://openradar.me/7019347 (Sven-S. Porst)
I’m just going to go ahead and dub this the Sven-S. Porst version. He’s done a lot of awesome work. Hats off, Sven. Great work.
This version also makes good on my beta appcast threat. Indeed, I concurrently released version 1.6b6 which is functionally identical to 1.6b5, but which utilizes the beta appcast.
The downside is as soon as you manually update to 1.6b5, you’ll get a notice 1.6b6 is available for auto-updating.
I know that’s kinda sucky to have to auto-update right after you’ve manually updated, but we need users to exercise these code paths and those are the arrows you take for being the pioneer, hotshot.
I briefly mentioned Flash cookies in a previous post in the context of ClickToFlash, but the topic warrants its own posting.
Flash cookies (aka “Flash Local Shared Objects”, aka “Flash Web Site Storage”) are like normal browser cookies — smallish chucks of data the client stores on behalf of the server for various purposes.
Flash cookies go beyond browser cookies in a few important ways:
Flash cookies can store more data than browser cookies. Up to 100K without user intervention.
Flash cookies span browsers. If you jump between Safari, Camino, Firefox and Chromium, normal browser cookies won’t follow you, but they all use the same Flash plugin with the same storage backend.
Sites can use Flash cookies to resurrect browser cookies. I attended a DEFCON talk a couple of years back that illustrated the use of Flash cookies to back-up user-deletable browser cookies. Of course, it’s easy to delete Flash cookies as well, but it’s a lot less obvious to go to a specific web page than look in your browser’s preferences window.
Flash cookies never expire by default. A lot of sites manually clear these out for you, but you’re relying on the kindness of strangers there.
For all the above reasons, Flash cookies have become one of the factors behind my recommendation to disable automatic loading of invisible flash views in ClickToFlash.
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:
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.
Currently we don’t post betas to the ClickToFlash appcast, and mostly I’d like to keep it that way.
But we obviously need a mechanism to get more folks on betas and keep them more up-to-date. My announcing via twitter isn’t scaling.
Current idea:
Two appcasts:
appcast.xmlfor golden releases,appcast-beta.xmlfor beta releases.appcast-beta.xmlis a strict superset ofappcast.xml— it lists betas as well as golden releases.Folks who download golden releases only get golden updates (technically: they follow the golden appcast).
Folks who download a beta release get beta and golden updates (technically: they follow the beta appcast).
Which appcast is followed depends on a hidden boolean user default:
useBetaAppcast. Nonexistent or false, the golden appcast is used. True, and the beta appcast is used.useBetaAppcastis set totrueopen loading ClickToFlash’s plugin when the version number contains a “b”.
Effects:
Golden users only see golden releases. All beta-ness is hidden from them. I think this is our common case.
Folks who try betas, get beta updates as well as golden updates.
One downside is once a user tries a beta (even once), they’ll always get beta update notices from then on unless they issue an explicit
defaults write com.github.rentzsch.clicktoflash useBetaAppcast -bool false. Not ideal if the user just wants to try a beta once but then goes right back to only golden releases.
Notes:
Instead of using a persistent user default (
useBetaAppcast), we could simply detect whether the current version is a beta and then offer beta updates.The upside to this there’s no hidden user default that we have to explain and offer tech support for. The downside is once a user jumps to a golden version again, they lose future beta updates.
We could offer yet another visible preference setting in ClickToFlash’s Preferences window to explicitly control which appcast you follow, but we’re trying really hard to limit options in that window.
ClickToFlash is a WebKit plugin. WebPlugIn plug-ins are new, based off a new Objective-C API.
Chrome/Mac currently supports the older Netscape CFPlugIn-based API, but not WebPlugIns. So it’s not just a matter of flipping an Info.plist flag or recompiling ClickToFlash to support Chrome — it may need a re-write.
I haven’t really looked yet so see what work it would take — we may be able to create a plug-in API bridge of sorts that allows ClickToFlash to target both browsers simultaneously (though you’d probably need to separate binaries).
I talked to Chrome’s plugin API engineer at WWDC09, and she’s down with ClickToFlash and wants to help us light it up. Happiness.
Interestingly, I think this would also give us Firefox support.
Update: Now it doesn’t look like we’d get Firefox support for free. Don’t really care, since I hear good things about Flashblock.
