Safari 5 Extension Development | Hacker News Reader

Safari 5 Extension Development

developer.apple.com

55 pointsswannodette28 comments

Interesting, in the Messages and Proxies[1] page, Apple has ad-blocking as an example which actually blocks the ads from being loaded using the `beforeload` event (as oppose to hide them after they're loaded):

> Safari 5.0 and later (and other Webkit-based browsers) generates a “beforeload” event before loading each sub-resource belonging to a webpage. The “beforeload” event is generated before loading every script, iframe, image, or stylesheet specified in the webpage, for example.

Isn't this exactly what the NoScript's author says Chrome extension was lacking[2]?

[1]: http://developer.apple.com/safari/library/documentation/Tool...

[2]: http://hackademix.net/2009/12/10/why-chrome-has-no-noscript/

Even if it was, I can't say I've ever understood the people for whom blocking ads was so paramount they'd rather have a page load slower so the ads would never even be glanced, versus a page that loads fast and hides them afterwards.

It all seems a bit backwards, to me.

Why would they be perceptibly slower?

My experience is exactly to the contrary. Often ads are loaded from some horribly slow server and it slows down the browser which has to wait for them, reflowing the content after each one. Not to mention that ads often change when the page is reloaded, so they're not cache-friendly either.

Compared to downloading the ads, the overhead of running a blocker is negligible, no matter how fast your connection is.

I think it's the main reason Chrome (even with the ad blocker) actually feels slower on many sites compared to Firefox with AdBlock. It may win in terms of raw speed, but Firefox actually has to spend less effort loading the resources, which is a larger gain.

I think in order to make NoScript work you'd also need the ability to block <script> that is inline, not just script that is loaded remotely.

I think the event will include inline contents too, but there's no way to test it right now since it doesn't seems to be enabled in the the current release of Safari 5.

Can I be honest and not be thought less of for it?

I actually like Chrome's "load then hide" version of AdBlock because the ad impression counts. It doesn't do much for PPC ads, but for PPI, the website owner has "made an impression" with the ad unit.

Of course, it's robbing the advertiser at the same time....

I'd rather it not count. AdBlock originated out of a deep annoyance/hatred for distracting, exploitative ads - but has since grown to cover just about every advertiser out there, good and bad.

Many people install AdBlock without seemingly realizing this difference. What I would like to see a much more discerning ad-blocking solution that punishes scammy, distracting, or otherwise abusive ads, and rewards advertisers that create consumer-friendly ads.

With a load-then-hide system the website owner has fewer effective metrics on whether or not people are actively blocking his ads. Perhaps when his impressions start dropping precipitously he would be much more compelled to act.

Of course, all of this hinges on the existence of a trusted adblock source that takes upon itself great pains to maintain a list that bans only abusive advertisers. I'm not holding my breath.

Me too, I'd like to see a block list that only blocked annoying ads. I actually blogged about annoying advertising here: http://posterous.richardcunningham.co.uk/the-problem-with-on...

On the flip side, it still leaves you vulnerable to Flash-based exploits and consumes related resources (thus increasing overall load time), which is one of the biggest benefits of a pre-block system.

For those who want to see a naive extension in action, I did a quick version of Helvetireader to the Safari extension format. It's trivial, but it also is a good template for further injection projects:

http://kirindave.tumblr.com/post/675464589/safari-5-port-of-...

My big question is: will these make it to the iPad version of Safari?

> My big question is: will these make it to the iPad version of Safari?

I really, really hope so.

How does it work? I installed it but I can't find a way to activate it.

Enable Safari's developer menu. (Preferences → Advanced → Show developer menu)

Then enable extensions. (Develop → Enable Extensions)

I got that far, but I guess I don't know what the extent ion actually does. How do i use it?

You then must find extensions to install. They can be downloaded from any website, and installed by the browser. Here's one repository of Safari 5 extensions I was able to find:

http://safariextensions.tumblr.com/

I wrote a really simple extension that injects jQuery into the current webpage. Not very practical as the same features can be found in a bookmarklet, but fun to make nonetheless.

http://conroy.posterous.com/jqueried-a-safari-5-extension

Before this, how did third parties add functionality to Safari? For instance, the button 1Passwoed puts in the toolbar and the item it adds to the context menu for form fields?

Using InputManager[1] or SIMBL[2]. There are several things Safari Extension is not capable of due to lack of API (anything not involving webpage data) so InputManager/SIMBL-plugins are still necessary.

[1]: http://www.cocoadev.com/index.pl?InputManager

[2]: http://culater.net/software/SIMBL/SIMBL.php

They used other OS X features that weren't meant for browser extensions. That means they tend to break when Safari is updated, and Apple killed a whole class of them in Snow Leopard. And they didn't work on Windows Safari, of course.

Snow Leopard broke a lot of the extensions built using Input Managers, so 1Password 3.0 used the Scripting Additions method.

http://kevin.sb.org/2009/09/02/1password-extension-loading-i...

It would be nice if you could listen for events, specifically I want to know when a tab is closed so I can add a action to re-open the last closed tab.

Are all Safari 5 Extension will be free?

They're just packages that you download and install, so they could feasibly be charged for. I'm pretty sure it's impossible to hide the source code, however, so a copy would emerge almost immediately if you tried to make a market for yourself. So yes, effectively all Safari 5 extensions will be free.

I am no coder so pardon my naive question.

Is it possible for chrome and safari extensions to be interoperable, especially as they both have the same underlying web-kit technology? Surely, we do not want another platform fragmentation and battle. I am sure developers would love do no more work than recompiling the extension they built for Chrome. It will be a win for everyone.

Nope, different interfaces to the underlying webkit functionality. And they're packed up differently.

I suppose the core functionality of more advanced extensions could be shared, with only different interface glue, but with simple ones, it won't be worth the bother to try to share.

There is no technical reason why this couldn't work, but my guess is that abstraction libraries will be necessary because Apple and Google won't be able to a agree on a common API. I kinda agree because having to standardise HTML, CSS and JS is hard enough and the browser makers don't wanna open up another battle front. Also, being able to tailor the API tightly to the underlying browser will attract developers and therefore enable more competition.

Good times for add-on developers!

In the same vein of commonJS, they should get together and create commonXT

Reply on news.ycombinator.com