Homebrew-cask: Safari extensions feature request

[rootbeerguy]

Is there a way to install Safari extensions using homebrew-cask? I did not find any previous examples of this being done.

One extension that I would like would be AdBlock which can be found at https://getadblock.com.
I also did not attempt to make a new cask with this extension.

A user could download from this URL:
https://data.getadblock.com/safari/AdBlock.safariextz

Then homebrew-cask would install:
AdBlock.safariextz

[rolandwalker]

I would like this as well. The problem is that we are CLI and Safari is GUI.

The standard way to install a .safariextz file is to open it in Safari. One can even do so from the command line with open -a Safari AdBlock.safariextz, but that requires interacting with the GUI to continue, which is contrary to our core mission.

Another plausible way is to directly manipulate ~/Library/Safari/Extensions/Extensions.plist, and possibly also ~Library/Preferences/com.apple.Safari.plist, after copying .safariextz file to ~/Library/Safari/Extensions/. However, I'm pretty sure that isn't safe when Safari is running.

Force-quitting Safari might be a reasonable approach; it would need some discussion. Another way would be to fail install with a helpful message unless the user quits Safari separately.

It would be nice to be able to install Firefox Add-ons as well.

[vitorgalvao]

@rolandwalker I’ll advise against the possible difficulties (impossibilities?) of this. As someone who tried/is trying to directly edit specific files for iCloud-enabled applications (the Reading List in Safari, and the database in Clear), I can tell that so far it has been a world of pain. Those files aren’t meant to be edited “by hand”, and even if you do manage to alter them and make them work, more often then not they won’t sync to other devices, and may even cause sync conflicts.

Just look at the amount of work and files that have to be _precisely_ manipulated just to accomplish the same that would be done by opening them with a GUI. There are too many points of failure. Not to say it couldn’t be done, naturally, but it will be a world of pain, with lots of intricacies that will only become clear after things start to break. And that is just until Apple (or Mozilla, or Google, or Opera Software) decides to change one little thing. I truly believe we’d have better luck convincing upstream (likely not Apple) to implement such features than ever making the work needed for this be worth it.

I might, naturally, be wrong here. Regarding browsers, I’m guiding myself by previous iCloud-sync-related issues, as well as your description of what would need to be done in Safari, and all the work I’ve had to go through to find an acceptable solution in Chrome, which actually has a lot of CLI options, and not a great one for this (as you might guess, that code still needs it to open and close a ridiculous amount of times, and still requires clicking around).

[rolandwalker]

In this case plutil -p ~/Library/Safari/Extensions/Extensions.plist seems to suggest a quite simple structure.

But yes, it would take lots of testing to make sure it was correct, and yes, there are lots of intricacies/points-of-failure, which is likely why nobody has taken the time to work on this.

There are some examples to work from, though. I noticed in passing just the other day that the avast pkg file installs a Safari extension via a postflight shell script.

My larger thought is that part of our practical niche and part of the impetus of our community is that we do things that the App Store doesn't (like focus on OSS). MAS is never going to provide browser add-ons, which makes me curious to at least explore the domain.

(That's part of my interest in providing fonts as well.)

[bcomnes]

What about just tracking the plugins as formulas, downloading them and then opening then and letting safari handle the installation? I know that defeats the purpose of the hands off installation, but at least it captures the hands off tracking and downloading of specific plugins. iCloud doesn't sync addons does it?

[vitorgalvao]

@bcomnes It’s part of the goal of homebrew-cask to never call a GUI, so that is no good.

[danielbayley]

+1 for this if possible.

[vitorgalvao]

@danielbayley Unlikely it’ll happen.

[vitorgalvao]

Closing for lack of interest/implementation. This is definitely non-urgent, and can be revisited later.

[eivindml]

Would love to see a feature like this.

[vitorgalvao]

@eivindml Then you’ll have to implement it yourself (or pay someone to do it) because there’s not enough return on having the team spend their time on this.