The Last Holdout of Basic Favicon Decency

Sat, 12 Sep 2026 00:00:00 +0300

Technology is constantly evolving—to serve you better. Or simply to serve better. The distinction, as always, lies in who pays for the serving.

Let’s play a game: here are some browser tabs. Find Safari:

Show the GIFs

Try the test yourself

Have you noticed something? I’m not talking about the spinning dots; those are really hard not to notice. The less obvious point is that Safari stubbornly refuses to spin its favicon.

“It’s clearly a bug,” thought some naïve, natural-born asshole¹, and duly filed a WebKit bug report. It made my day. I literally cackled—which, unlike most uses of LOL, means that I actually laughed out loud.

Just put yourself in the shoes of those poor, hard-working site owners, will ya? You had the audacity to rudely decline their website’s offer to send notifications through Apple’s Notification Center. But you, of course, really need the spam more than anything else you might be trying to do at that moment. The conclusion is easy and obvious for them, decency-wise. So let them draw animated attention-grabbers! Surprise: technology has evolved to do just that. As if it had heard the market’s demand.

Of course, these won’t be merely tasteless, old-school, dumb animated GIFs spinning a “NOW FREE!” ad purely to steal your attention—oh no! This is sophisticated technology that kicks in only when there are real updates that you, as we all know, really, really need, and draws tasteful little red circles with numbers—the kind you know and love from pretty much everywhere. And anyway, if you tried to sue Google over Chrome foisting animated favicons on us, you’d lose. Chrome merely allows a static favicon to be replaced eight times a second. Those are moving pictures, Your Honor—not a movie.

You wouldn’t dare sue Mozilla; it’s a nonprofit lamb among evil corporate wolves. It simply does not want to deprive developers of their freedom to write anything they please in their code.

Only Apple, the evilest of them all, has not yet failed its users in the face of these demands from the advertising industry. Why? Specifically because it is evil. It counts its money, like any good evildoer. And unlike the organizations behind “free” Chrome and Firefox, it gets its money directly from you when you buy an iPhone or a MacBook, rather than through a cut of ad revenue. For now, at least…

P.S. I was unable to find any way to disable dynamic favicon changes in Chrome. Firefox’s situation in this regard is downright comical: the request for a way to disable animated favicons has been gathering dust for the past 24 years.

P.P.S. “Why do you use a Mac? It’s so expensive!” Well, precisely.

Anyone who does not respect the value of other people’s time is an asshole in my book. Yes, that means the software industry and internet businesses alike are populated by assholes of 80–100% purity. That’s the world we live in. What can I say? ↩︎

The Picky Reveal

Thu, 19 Feb 2026 00:00:00 +0200

My script needs to open a Finder window with a particular file selected. There is an AppleScript command exactly for this purpose: reveal.

set theFile to POSIX file "..."
tell application "Finder"
	activate
	reveal theFile
end tell

The problem is that there is no way to say “be dumb and just create a new window.” No, the command is always smart-alecky and invariably reuses an existing Finder window if one is already displaying the folder of the file to be revealed (called the target in Finder dictionary terms). For scripts, this behavior creates two unwelcome side effects:

How do you distinguish a newly created window from a reused one? I want to close the new window but leave the reused one alone.
Worse, if the current Space has no window to reuse but another Space does, Finder will happily reuse the window in that other Space — and that breaks everything. Programmatically, Apple treats Spaces as separate universes, and scripting across Spaces is not something I’m eager to do or recommend.

The solution seems straightforward: just open a new Finder window and set its target in advance to the folder of the file to be revealed:

-- innocent-looking 
set theFile to POSIX file "..."
set theFileFolder to POSIX file "..."
tell application "Finder"
	activate
	make new Finder window
	set target of the result to theFileFolder
	reveal theFile
end tell

But it does not work. The new window is created, it shows the correct folder — yet reveal completely ignores it as a target candidate, as if it doesn’t exist.

And this is not an AppleScript issue. The “Show in Enclosing Folder” command in Finder and the “Reveal” action in the Shortcuts app behave exactly the same way. Somehow the window is not kosher enough for revealing.

Long story short, there appears to be a bug somewhere inside the implementation of the target property that corrupts something in the Finder window’s internal metadata if you pass an alias directly.

The fix:

-- somewhat enigmatic fix
set theFile to POSIX file "..."
set theFileFolder to POSIX file "..."
tell application "Finder"
	activate
	make new Finder window
	set the target of the result to (get folder theFileFolder)
	reveal theFile
end tell

By the way, the following variant doesn’t work. The entire

set the target of the result to folder theFileFolder

statement is compiled into a single Apple event under the hood, and the problematic alias is buried inside it as a parameter. In contrast, the explicit get command in the working version forces AppleScript to generate two separate Apple events.

-- not a fix
set theFile to POSIX file "..."
set theFileFolder to POSIX file "..."
tell application "Finder"
	activate
	make new Finder window
	set the target of the result to folder theFileFolder
	reveal theFile
end tell

If you want your source code to look less enigmatic, you can introduce explicit variables:

-- less of enigma
set theFile to POSIX file "..."
set theFileFolder to POSIX file "..."
tell application "Finder"
	activate
	set theWindow to make new Finder window
	set theTarget to folder theFileFolder
	set target of theWindow to theTarget
	reveal theFile
end tell

On All Things Considered

The Last Holdout of Basic Favicon Decency

The Picky Reveal