-
-
Notifications
You must be signed in to change notification settings - Fork 132
Fix Force favicon refresh with cache-busting for notification state (Safari compatibility) #2264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Manipulating the DOM like this discouraged in react. Use the relevant components to do this.
Are you testing on Safari? Just making sure you're on the right path as the favicon reliably changes on other browsers, just not Safari (in the issue I linked Apple's response) |
yuh, i had to download safari all the way, log into github, check 2FA and then log into sndev |
done :) |
i downloaded it from browserstack (sort of macOS vm) and as for that, i was afraid of this exact thing. next.js merges tags, and if the only change is the href, some browsers may not reload the favicon. the approach using with a cache-busting query string is React-compliant, but some browsers (especially Safari) may not update the favicon reliably unless the tag is actually replaced in the DOM, not just updated via React's virtual DOM. but @huumn says that it is discouraged.
I am sorry if I prove myself incompetent but that was the only fix I could wrap my mind around. I'll revert the changes. I'll be glad to know if there is another alternative fix to the problem. |
There's no need to feel bad about trying. I did warn you that Safari intentionally doesn't support favicon changes via JS, because of some privacy/user-protection things or whatever excuse they come up with. It's not the first time that we had to come to terms with Safari behaviors, and it won't be the last time. One thing: QA, QA, QA. It's important. It's clear that you might be learning, just don't expect things to magically work if you don't test them or slightly don't understand them, especially if it's the product of predictive models. Thank you for trying. |
Description
Closes #2256
Changed the favicon URL each time (by appending a query string
?v=timestamp
), which can force Safari to reload the favicon each time the notification state changes. This increases the likelihood that Safari and other browsers will reload the favicon immediately.Screenshots
not really applicable but still I clicked before and after screenshots for unread notifs thrice, while the tabs were bookmarked

Additional Context
When I had an unread notification, I bookmarked the tab while it was unread and of course it saved the icon with the red square. Then I reloaded the site and read the notif, this updated both the bookmarked icon and the actual one. Next 5 times I refreshed the site at different time intervals; there was no error.
Checklist
Are your changes backward compatible? Please answer below:
yes
On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:
9
For frontend changes: Tested on mobile, light and dark mode? Please answer below:
yes
Did you introduce any new environment variables? If so, call them out explicitly here:
none