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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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...
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.
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.
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 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.)
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.
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.
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)
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.
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.
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...