Don't allow animated favicons (2001) | Hacker News Reader

Don't allow animated favicons (2001)

bugzilla.mozilla.org

119 pointsgraderjs85 comments

Safari unfortunately goes too far the other way, it very aggressively caches the favicon so it can't be easily updated for things like unread counts.

Gmail has a useful feature you can turn where it shows you unread email count in the favicon, great for pined tabs. It's completely useless in Safari, just gets stuck for days at a time.

https://apple.stackexchange.com/questions/339350/safari-12-f...

That could be a tracking protection feature in Safari? https://news.ycombinator.com/item?id=26051370

The part where the author files a bug to get caching "fixed" in Firefox is also interesting. https://bugzilla.mozilla.org/show_bug.cgi?id=1618257

Edit... Sorry. Actually, I forgot how the abuse worked, it relies on persistent caching. So Firefox doesn't cache, preventing bookmark tracking. Safari aggressively caches, so would. Any amount of caching would be a problem.

Hm... unless Safari never checks for updates to the Favicon at all. That would defeat the exploit as well. So very aggressive caching with no check for updates, also good? Ok. I stand by my original guess :)

If it's to prevent tracking I'm all for it, but I would love them to then provide an API to enable favicon overlays for badges/notifications (in a tracking abuse free way).

Maybe, just maybe, with the news they are finally implementing Web Push Notifications and the suggestion it's the first step towards supporting PWAs, they might create a icon badge api for both the favicon but also PWA icons.

>That could be a tracking protection feature in Safari?

Heh, that feels like the Web in a nutshell:

Devs: "Hey, wouldn't it be convenient if we cached--"

Advertisers: "Aha! Another means to track people!"

Classic "that's not a bug that's a feature"

omg, thank you. I've always wondered why my work email count was wonky.

Quoting Apple engineer Brady Eidson: "We (Apple) intentionally do not want the ability to script favicons."

source 1: https://bugs.webkit.org/show_bug.cgi?id=95979 source 2: https://bugs.webkit.org/show_bug.cgi?id=75877#c1

Thank you, I went looking for the bug report but couldn't find it.

2012 is a long time ago in the time of the web, hopefully opinions have changed. I think back then Safari didn't have the ability to show favicons in the bookmark toolbar where this is useful, it does now.

This is part of apples model that the web is for static reference material, and anything more complex should be an app in the apple ecosystem.

Apple goes to great lengths to make sure webapps can't be too useful for the user.

Yep. And I love how they add in broken behaviour for things like still not being able to properly scroll elements which have `position: fixed`. Or trying to make the page have a static fixed height while scrolling.

Sound is weird on iOS web. Also, they basically unilaterally decided to say "nah, we're good" to web Bluetooth. I think that could have opened up a lot of awesome stuff. As it stands, getting that to work is possible but the steps to get there are multiplied ten-fold.

Thank god that Apple never implemented web Bluetooth. One more thing that I don’t have to worry about my web browser mucking with. Please keep the browser out of my peripherals.

Seriously. Why does everything have to be a web API.

Because distributing apps to iOS isn't commercially viable?

I could see Bluetooth support maybe making sense for PWAs the user has explicitly chosen to add to their Home Screen, but I really don’t want to see random sites I’m visiting prompt for access.

I find it weirdly interesting when people argue that a browser shouldn't have a feature, rather than the feature should be behind a defaults-to-off permission. You're not just saying that you don't want it, you're arguing that no one should want it. You're saying that you don't believe there is any possible reason for the feature to exist, that you will never want it, and that anyone who says they'd like it is wrong.

I suppose that's fine. It's your perogative. I just hope you respect the opinion of other people when they say things you want shouldn't exist.

I don’t think it’s unreasonable to not want a browser to support hard-to-maintain features that you will likely never want or use. There is a limited pool of dev resources, and supporting that defaults-to-off setting is going to suck up a disproportionate amount of dev resources, on an ongoing basis, to support a small minority of users.

I’d rather the dev resources go to new features that many people will use.

Javascript was behind a "defaults to off" switch, until enough of the Web said "fuck it, we'd rather break than provide a person with what they've specifically requested and set a limit on". And now those of us who point out that mandatory JS is broken and a vector for all manner of ills are thought to be deranged.

I'm not often an Apple fan, but I have intense admiration for this line they've drawn in the sand.

This seems to be Apple's design philosophy. I can't change the direction of my touch pad scrolling without affecting my mouse scrolling, I had to download a third party app for that. Their defaults are so stubborn, if you don't like it the way they believe it should be it's either annoying or impossible to change it.

In my experience, when a platform adds support for something like that, apps quickly start requiring that you have the feature on, even unrelated apps. For example, a ton of apps, especially sketchier ones or ones aimed at children, ask to see your location even though they have no legitimate use for it. If you don’t allow it, you can’t use the app. Obviously what they’re using it for is datamining, so I’m worse off than in the world where the app isn’t able to ask for location access.

Obviously it’s good that some apps do have access to location! I play Pokemon Go and use third party map apps! But I think the world would be better off if the requirements to be allowed to ask were more stringent.

For something like web bluetooth, while there are some rare use cases, I’m sure that pretty soon it’ll start being another tool for removing privacy and I’d rather err on the side of caution.

From an entirely separate side, I think that we’d all be better off if the entire web was much simpler to implement. We’re almost in a browser monoculture now and we wouldn’t be here if it weren’t so difficult to implement a browser that supports modern websites.

Another case of apple ignoring standards in favor of their own preferences.

It is but I don’t see that as a bad thing on this occasion because diversity in rendering engines, even if some are opinionated, is better than a Blink monoculture (or Trident before it)

I would not mind if it was possible to switch but a lot of people are stuck with safari mobile.

That’s a different issue though. But I agree that’s a problem.

User agents are explicitly allowed to have their own preferences, that's the whole point of having multiple browsers in the first place. If you want every browser to be identical then why even have more than one? Browsers don't even have to have display favicons if they don't want to.

> Another case of apple ignoring Google in favor of their own preferences.

Fixed that for you.

I absolutely agree. Animated favicons would be extremely jarring. It’s purpose is to identify the site. It does that job perfectly.

The web is already a fricking Casino.

'The Web is a Casino' sounds like an amazing title for a polemic.

I find them useful in some cases. I play board games online, and both sites I use will update the favicon (either with a new color or an animated shape) to tell me that it's my turn.

Sounds like that use case really wants something like silent push notifications (no sound, no toast, but it's there waiting when you decide to pull down and look for updates from all apps in one place). Yes, I said push and pull to describe a sort of hybrid model. Android offers this, but I'm not sure if desktop OSes do.

I think people would prefer notifications here, but Safari doesn't support that either.

Desktop Safari supports notifications, it’s only mobile Safari that lacks them.

"Animated" is one thing, allowing updates every once in a while is another.

I totally agree with that, but couldn't the favicons still support the same browser caching mechanisms as the HTML document? If I can refresh the page and get a new HTML response, surely I should at the same time get a new favicon if a new one exists.

Most people probably wouldn't want to refresh an SPA like Gmail every time the favicon isn't showing the correct unread count. But for infrequent rebranding, I agree with you.

Yes, I'm not trying to address the feature of having animated favicons or favicons set dynamically using JS. I'm just trying to address the problem of favicons apparently being very stale. My question is why Apple couldn't fix that problem, which is not at odds with Apple's stance against animated or dynamic favicons.

That would allow websites to override Apple's objection, and therefore they can't allow it, even if it will cause occasional problems for websites that think they can do a total branding pivot including favicon overnight.

Why is that related to Apple's object to animated favicons or favicons that are set dynamically by JavaScript?

If Safari didn’t aggressively cache favicons, websites trying to overcome Apple’s objection would immediately start trying to use window.reload() and server-side dynamically generating favicon paths, for random “I made this up before coffee” example, which would burn more battery power on Apple devices for endless page reload events. Caching aggressively makes it a non-starter to try and engineer workarounds, and comes at zero impact to users (who are either accustomed to the old favicon and don’t care about rebranding, or ignoring it).

I mean, the optimal solution is obviously a web standard that allows for notification badges on tabs. Each site changing their favicon to show a notification badge is a hack.

Could it be done using JS to put the count in the page title? I realize Unicode and emojis might not be ideal but they could supplement such an approach.

Isn't caching a different issue than playing the animation? The Mozilla issue was (initially) focused on stopping ongoing distracting animations.

Or just use a native application instead of butchering the web to do a poor job of it.

I like that Mozilla doesn't have one of those auto-close bots that are so popular these days on Github.

Only two extremes are proposed, static or fully animated...

There is a middle ground: changeable at a low frequency e.g once per 20 secs, allowing useful features such as indicators, counts, status changes etc while neutering distracting animations.

Once every 20s is too frequent by several orders of magnitude for me.

I absolute detest and despise animation to a degree that is hard to express.

I hate cooked spinach but it doesn't mean you shouldn't be able to eat it.

Your eating spinach wouldn't generally mean I am subjected to it.

Browser support of behaviour in specific features without means to disable it has immpacts on those who have an extreme aversion to it.

How could once every 20s allow someone to create an animation or be annoying?

If it is I'm sure someone could create a browser extension to stop it completely

Something changing on my screen every 20/60/whatever seconds that is not conveying desired information would really annoy me, it gets my attention.

I can assure you that in my case it is.

Chrome/Android does not support browser extensions. It is a platform used by billions of people.

I suspect a few may share my response to animations.

There is something fascinating to me about casual discussions that span 20 years or more. One day someone will bump a thread on a forum and answer a question that was asked before they were born.

IIRC There was some decade-plus Mozilla bug over here on HN a few months ago where the newest comment was like "So the OP was my dad, and he's now dead. Anyway, here is some additional info"

Incredible. 2 months ago I got an email notification for a Mozilla bug that I subscribed to years ago. It was based on a difference between Chrome and Firefox for one of the first web projects I ever worked on. Now I'm thinking of revisiting that project

A similar thing happens on usenet with people replying to old posts via Google Groups. Though it is interesting to read through a discussion thread I've posted in nearly 25 years later.

Fun fact, I created the first every animated favicon on the web for MozillaNews.org. Literally the night the patch landed in nightlies for supporting any format image for favicons, I created an animated one for MozNews and pushed it live.

A copy of it from the Web Archive: https://web.archive.org/web/20040921022312im_/http://mozilla...

(Yes, that date is late in the site's life, because I just wanted to grab the image.)

> I created the first every animated favicon on the web

Did you mean "very first animated favicon" or "first ever animated favicon"? Either way, very cool :)

Typos! Yes, the first ever, not first every. And to be clear, yes, I think they're a bad idea because they're too easy to abuse.

I hate you for your first comment in this thread, and love you for your second.

Dr. Ian Malcolm strikes again: "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."

I will accept both judgments. :D

This is the kind of thing where everyone thinks the right behavior is really obvious, but those expectations conflict, being drawn from the assumption that one's own preferences and habits are normal, and techie narcissism inflates the importance of the whole thing to nutty size...

Typical Mind Fallacy

https://www.lesswrong.com/tag/typical-mind-fallacy

This thread is incomplete without a link to Defender of the Favicon (Defender-linke game in the favicon)

http://www.p01.org/defender_of_the_favicon/

DOOM favicon can not be left out either: https://vidferris.github.io/FaviconDoom/favicondoom.html

How is that a bug if pages can still change, and thus animate, the favicon via JS?

As alluded in the comments on that bug, people sometimes actually use animated gifs but almost nobody does the animation via CSS. That said I can't even remember the last time I saw an animated favicon.

I made this for a catering service

http://img.go-here.nl/favicon.gif

Hilarious and cute at the same time.

wonderful

JS modifying favicon would be a bug.

AFAIU Faviocon was meant to differentiate browser bookmarks and tabs to make it easier to tell which is what.

In March 1999, Microsoft released Internet Explorer 5, which supported favicons for the first time.[4] Originally, the favicon was a file called favicon.ico placed in the root directory of a website. It was used in Internet Explorer's favorites (bookmarks) and next to the URL in the address bar if the page was bookmarked.

https://en.wikipedia.org/wiki/Favicon#History

The fundamental problem is that tabs are already a misfeature of sorts.

https://old.reddit.com/r/dredmorbius/comments/256lxu/tabbed_...

Depending on the browser’s favicon parsing, you can do some odd things with it by adding a new <icon> element. I was looking at this the other day and was able to get a basic example of blinking it together (the “What about the favicon?” section from https://alexanderell.is/posts/attention-javascript/).

I swear the more I see of such things the more Gemini appeals.

Principle of minimum privilege and execution.

I just disable the favicon entirely. (But I agree that if it is enabled, it should probably not be animated. I personally still would not use it, though.)

I'm sure there are plenty of bugs like this in other browser but yeesh...

Unfixed for 20 years because it was an implementation bug no one in authority was willing to fix. No other browser even supports it!

Ugh.

There are plenty old bugs yes but does this one really count as a bug? It categories as "enhancement" and I personally agree it's more like a feature request.

Feature requests like this is precisely the place when saying "it's open source, just do it yourself" is a valid remark.

Don't you first need some kind of consensus where whoever is responsible says "Yes, we will accept this"?

I mean these 20-year bugs are a smell where there is indecision, I don't think it's a matter of nobody wanting to go into the code. Decide if it has to be fixed or changed, or explain why you won't, and close the issue.

(on that note, I don't like the "this issue is stale -> closed" on GH either, unless the maintainer(s) replied or asked for additional information and the OP abandoned the issue)

If your change is good, you can create consent by making the patch available. People will install it and eventually Mozilla will implement it.

In this case though, I doubt you'd get much traction because nobody really cares.

It took me more than half a day to get the repo cloned & make it compile. I won't attempt to contribute to firefox again.

Fun fact: Firefox was the first program I ever compiled. I’d just finished an online Python class and wanted to get involved in this open-source thing. Mozilla had some Python tasks but they still required a dev build of the browser. I was on Windows at the time.

It took me three days to figure out, and thinking about cygwin still makes me shudder.

Then I saw that the Linux instructions were just a one-line apt command for dependencies and then the build command. It looked magical.

This is what convinced me to move to Linux and exposed me to so much cool software and ideas. I never did end up contributing to Mozilla.

And then you do it yourself and your patch is never accepted because it disagrees with the other developers.

So you try to make an extension which implements the behavior you'd like, and it works pretty well for a couple years. But then they decide to completely remove their extension API, and instead give you one that doesn't even offer 0.1% of the hooks that the old extension API offered.

So at the end of the day you're forced to maintain your own private fork. Fortunately, the other developers attention is focused on other areas of the codebase these days (hopefully ones that are irrelevant to you), so you don't have to do a lot of conflict resolution.

Eventually, you switch to a source-based distribution where you can pile patches upon patches on each of the packages you use, and they are auto-reapplied every time you upgrade the package.

Such is the life of the "open-source software user with an itch" these days. It's still better than the alternative... at least on paper.

Is that even a bug? It's more like a unwanted feature hardly anyone uses and as such hardly anyone ends up caring about in either direction.

On the other hand changing the icon through JS is something people do care about (unread notification indicator) for example.

I seen one or two cases from "still icon" -js-> "animated icon" -js-> "still icon2" which where ok (or did they just do a lot of js refresh??).

I can't remember any side abusing changing or animated icons, tbh.

So if I would manage Firefox I probably wouldn't fix it either because it's not worth the time investment needed, while on a project the size of a browser there are basically always relevant issues to fix. (Exception maybe if I have to touch the code in question anyway and remember the issue.)

And the age in the end doesn't matter if there are always docents of way more relevant bugs, they always will get priority. It only would matter if I care about irrelevant stats.

Animated favicons remind me of <marquee> (and the later even more annoying <marquee behavior="alternate">).

<blink>

I would like to play 'Pong' in my flavicon. Damn it.

Reply on news.ycombinator.com