Disabled Safari Extensions Are Not Fully Disabled, and Other Problems ⇥ lapcatsoftware.com

A couple of days ago, I wrote up a short article for what I thought was a neat little workaround for being required to quit Safari to update a Safari app extension. This is a disruptive step for which developers have no workaround; it is just how Safari works.

But even though everything seemed to be okay on a surface level, something told me I should consult with an expert about whether this was a good idea.

So I emailed Jeff Johnson:

Following Nick Heer’s workaround, when you subsequently reenable StopTheMadness after updating to the latest version in the App Store while Safari is still open, Safari injects the updated extension’s content script and style sheet into open web pages that the extension has permission to access, which is typically all of them, including the pages with leftover content scripts from the previous version of the extension. Consequently, an App Store update can leave you with two different versions of the extension’s content script running simultaneously in the same web pages! This is a very undesirable situation, because the two competing scripts could conflict in unpredictable ways. You’ve suddenly gone from stopping the madness to starting the madness. In hindsight, therefore, quitting Safari in order to update extensions seems like a good idea, and that’s what I recommend to avoid potential issues and weird behavior.

After Johnson told me about this issue, it was obvious that posting my workaround was a bad idea, so I scrapped the post. But I think Johnson’s piece is worth reading to understand why the design of Safari extensions requires users to quit the browser to install updates. Of course I do not think it should, but what can you do?¹