Chromium fetching all my favicons all the time - angularjs

When using chromium, in my angularjs application, when I click on any link, all my favicons get loaded.
My main HTML page contains 10 lines like
<link rel="icon" type="image/png" href="favicons/favicon-57x57.png" sizes="57x57">
with size going up to 192x192. This might be wrong as it's just an "adaptation of something I found somewhere".
However it doesn't explain, why all of them get loaded every time, does it? All the links just change the URL after the hashbang and usually lead to no server request at all, apart from fetching 10 favicons.
Even if I did everything wrong, the favicon is global for the whole site, so there's no need to reload it, right?
With a little fiddling with the headers I can serve them with any of 200 OK or 304 NOT MODIFIED or 200 OK (from cache), but whatever I do, they all always get requested.
This doesn't happen in Firefox.

What you described is a known issue of Chrome, related to the fact that Chrome doesn't support the sizes attribute.
Firefox also used to be impacted, and it still doesn't support sizes. However, it doesn't load all icons anymore. As far as I know, this is not documented anywhere. This may have been fixed as a side effect.
There is no "solution" but a workaround: declare less icons. I suggest you to use this favicon generator. The generated images and HTML were designed with this issue in mind. For example, it does't generate the 192x192 PNG icon by default, because Android Chrome (the browser it is dedicated to) primarily uses the Webb App manifest. Full disclosure: I'm the author of this service.

Related

React App Favicon Not Showing while sharing website URL/Link [duplicate]

I have a Grails application running locally using its own tomcat and I have just changed the favicon for a new one. Problem is that I can not see it in any browser. The old favicon shows up or I get no favicon at all, but not my new one. I do not think this is a Grails issue per se, more an issue with favicons.
What is supposed to happen with favicons? How are they supposed to work? I have numerous bookmarks in my browser which have the wrong icons and they never seem to get refreshed. How do I force the server/browser to stop caching them? It seems pretty silly to always cache them given they are normally only 16x16. Why not just upload them with every visit to the page? It is not exactly a huge overhead.
To refresh your site's favicon you can force browsers to download a new version using the link tag and a query string on your filename.
This is especially helpful in production environments to make sure your users get the update.
<link rel="icon" href="http://www.yoursite.com/favicon.ico?v=2" />
Adapted from lineofbird's answer beloew, you can do the following:
Go directly to the favicon url in the address bar by typing in it's address e.g.
www.yoursite.com/favicon.ico
www.yoursite.com/apple-touch-icon.png
etc.
Navigate to the url by pressing Enter
Refresh with Ctrl+F5
Restart your browser (e.g. Chrome, Firefox)
This answer has not been given yet so I thought I'd post it. I looked all around the web, and didn't find a good answer for testing favicons in local development.
In current version of chrome (on OSX) if you do the following you will get an instant favicon refresh:
Hover over tab
Right Click
Select reload
Your favicon should now be refreshed
This is the easiest way I've found to refresh the favicon locally.
By destroying the file your browser uses to store old favicons, you can force new ones to be loaded.
Close your browser. Make sure there are no longer browser processes running (e.g. check Task Manager for chrome.exe or firefox.exe).
Navigate to where your browser stores user files:
For Chrome, go to the Chrome data directory.
For Firefox, go to the Firefox profile folder.
Delete the favicon cache.
For Chrome, remove Favicons and Favicons-journal
For Firefox, remove favicons.sqlite
This will almost definitely work. If not:
Possibility 1: An update to your browser has changed how the favicon cache works. Please edit this answer with new instructions.
Possibility 2: Your favicon problem has nothing to do with overaggressive caching. It may instead be a resource-loading problem – using Developer Tools, make sure the new favicon is downloading properly.
Rename the favicon file and add an html header with the new name, such as:
<link rel="SHORTCUT ICON" href="http://www.yoursite.com/favicon2.ico" />
If you use PHP you could also use the MD5-Hash of the favicon as a query-string:
<link rel="shortcut icon" href="favicon.ico?v=<?php echo md5_file('favicon.ico') ?>" />
This way the Favicon will always refresh when it has been changed.
As pointed out in the comments you can also use the last modified date instead of the MD5-Hash to achieve the same thing and save a bit on server performance:
<link rel="shortcut icon" href="favicon.ico?v=<?php echo filemtime('favicon.ico') ?>" />
In Chrome on Mac OS X one can remove file with favicon cache
${user.home}/Library/Application Support/Google/Chrome/Default/Favicons
Depending on the browser they are handled differently, but typically I find that going to the default page of the site, and doing a hard refresh. CTRL + F5 (or ⌘ Command + SHIFT + F5 on macOS), will typically get it to update.
Well, overhead is overhead, but yes, not too big.
Also, browsers are sometimes "greedy" about cached files. You could clear cache and/or restart your browser and may see the change. If that fails though...
My cheapo solution is to:
Visit your file at http://example.com/favicon.ico in your browser.
Delete the favicon.ico from your webroot.
Visit http://example.com/favicon.ico again in a browser, verify it's missing.
Upload new one to your webroot.
Visit http://example.com/favicon.ico again in a browser, verify it's the new one.
If that sequence doesn't work, then something else is going on.
ON MAC:
⌘ + Shift-R or hold down Ctrl and click the reload button in the browser.
For Internet Explorer, there is another solution:
Open internet explorer.
Click menu > tools > internet options.
Click general > temporary internet files > "settings" button.
Click "view files" button.
Find your old favicon.ico file and delete it.
Restart browser(internet explorer).
More than likely a web browser issue. You will have to delete your cache from your browser, close your browser and reopen it. That should fix it.
I don't believe your favicons will get refreshed on your favorites until you revisit that page, and assuming that you had previously cleared your browsers cache.
Your web browser will not go out to the internet to check for a new favicon on its own... thank goodness.
Try Opening In a New Tab
I tried many of the things above (resetting cache, refreshing, using the link tag, etc), I even checked my .htaccess file and reset the ExpiresByType variable.
But this is what finally worked for me in both Chrome (25.0.x) and Safari (6.0.1):
Flushing cache
Hard-linking the favicon with the <link> tag
Navigating to mysite.com/favicon.ico
Opening mysite.com in a new tab
(Up until step 3, refreshing in the same tab kept reproducing the old icon.)
Chrome Version: 68.0.3440.106
Just restart Chrome (in your address bar):
chrome://restart
For Chrome on macOS, if you don't want to delete the entire Chrome favicon database as suggested already here, you can delete only the conflicting icons:
Quit Chrome
Load the favicons database (using sqlite here):
sqlite3 ~/Library/Application\ Support/Google/Chrome/Default/Favicons
Search for the file that is causing issues
select * from favicons where url = 'http://mysite.dev/favicon.ico';
If you are happy with the output:
delete from favicons where url = 'http://mysite.dev/favicon.ico';
Alternatively, you can search for a pattern that you can reuse to delete multiple entries:
Search for multiple files that are causing issues
select * from favicons where url like 'http://mysite.dev%';
And again if you are happy with what this returns:
delete from favicons where url like 'http://mysite.dev%';
Type .exit and hit return to quit sqlite
Restart Chrome
When you request the favicon from Google, you can take a look at the response headers.
Last-Modified: Fri, 09 Jan 2009 16:35:02 GMT
Date: Thu, 01 Dec 2010 00:00:01 GMT
Expires: Fri, 01 Dec 2011 00:00:01 GMT
Cache-Control: public, max-age=31536000
Age: 7
If you put an "Expires: " header on the response, client browsers will re-request the icon after that timestamp. While doing active development, you could set the expires timestamp to a second or two in the future, and always have it fetch this, although that's a poor longterm plan.
Chrome's favicon support is buggy - disregard this answer
I wrote this answer under the impression that this is what it took to refresh favicons in Google Chrome. However, it turns out that this only works for the first five minutes or so, until the icon gets irretrievably lost in Chrome's history synchronization.
Original answer
You don't have to clear your cache, restart your browser, or rewrite your HTML - you just need to change the icon's URL, once, so that the browser will forget the previously-cached icon.
Assuming that you've defined your icon via <link> elements in your page's <head>, you can do that by running this standard-JS one-liner in the console:
[].slice.call(document.querySelectorAll('head>link[rel$="icon"]')).map(function(ln){ln.href+='?v=2'});
For a more advanced implementation of this that can automatically do this for end users in production, see freshicon.js.
I recently restored my bookmarks and was looking for a way to restore the FavIcons without visiting each page. My search brought me to this thread.
For those in a similar circumstance merely download the FAVICON RELOADER addon. Once installed you will find the "reload favorite icons" command in your BOOKMARKS dropdown menu.
https://addons.mozilla.org/en-US/firefox/addon/faviconreloader/?src=api
If you are using PHP .. then you can also use this line.
<link rel="shortcut icon" href="http://www.yoursite.com/favicon.ico?v=<?php echo time() ?>" />
It will refresh your favicon on each page load.
If you are just interested in debugging it to make sure it has changed, you can just add a dummy entry to your /etc/hosts file and hit the new URL. That favicon wouldnt be cached already and you can make sure you new one is working.
Short of changing the name of the favicon, there is no way you can force your users to get a new copy
This is a workaround for the chrome bug: change the rel attribute to stylesheet! Keep the original link though. Works like a charm:
I came up with this workaround because we also have a requirement to be able to update customer's sites / production code and I didn't find any of the other solutions to work.
This works for Chrome:
on Mac: delete file
${user.home}/Library/Application Support/Google/Chrome/Default/Favicons
on Windows: delete files
C:\Users[username]\AppData\Local\Google\Chrome\User Data\Default\Favicons
C:\Users[username]\AppData\Local\Google\Chrome\User Data\Default\Favicons-journal
source
I know this is a really old question but it is also one that is still relevant, though these days applies only to mozilla. (I have no idea what explorer does coz we don't code for non standard browsers).
Chrome is well behaved if one includes an icon tag in the header.
Although mozilla are well aware of the issue, as usual, they never fix the annoying small stuff. Even 6 years later.
So, there are two ways of forcing an icon refresh with firefox.
Have all your clients uninstall firefox. Then re-install.
Manually type just the domain in the url bar - do not use http or www
just the domain (mydomain.com).
This assumes of course that your ns records include resolution for the domain name only.
Simple,
1: I don't want to fiddle around with codes (ps my site builder doesn't use codes, it uses "upload file" button and it does it itself)
2: I tried the CTRL+F5 and it doesn't work for me so....
I HAVE A SOLUTION:
IE: Clear All browser history and cookies by going to the settings cog O
Chrome: Go to the menu in the top right corner below the X that looks like a = , then go to settings, history, CLEAR BROWSING DATA and check all of the boxes that apply (I did history, cookies and empty the catche from the beginning of time)
Just change this filename='favicon1.ico'
Here's how I managed it with a simply animated favicon and FireFox 3.6.13 (beta version) It will probably work for other versions of FireFox as well, let me know if it doesn't.
It's basically artlung's solution, but addressing the .gif file as well:
I opened by FTP program, downloaded my favicon.ico AND favicon.gif files,
then DELETED them from my server's files.
Then I opened them in my browser as artlung suggested:
http://mysite.com/favicon.ico AND http://mysite.com/favicon.gif Once those addresses loaded and displayed 404 error pages ("page not found")
I THEN uploaded both files back onto my server, and PRESTO - the correct icons were instantly displayed.
Also make sure you put the full image URL not just its relative path:
http://www.example.com/images/favicon.ico
And not:
images/favicon.ico
Use query string at the end of the file path. Query string variable value must be different with every build.
if previous build is:
<link rel="icon" href="http://example.com/favicon.ico?v=v1" />
OR
<link rel="icon" href="http://example.com/favicon.ico?v=stringA" />
then next build should be:
<link rel="icon" href="http://example.com/favicon.ico?v=v2" />
OR
<link rel="icon" href="http://example.com/favicon.ico?v=stringB" />
Close all Google Chrome windows
Adding one more answer that I do not see here. I tried flushing my Google Chrome cache, reloading the tab, refreshing the tab, opening in a new tab, and even opening a new window. Nothing worked for me. What did finally work for me was to close all Google Chrome windows (if you're like me, you probably have 3+ windows with a bunch of tabs, and maybe even have more windows/tabs in another desktop, don't forget those!). Once all of your windows are closed, then try opening a fresh new window and reloading your site.
Hope this helps someone!
Bonus tip: If you'd like to get all your windows back, you can press "Ctrl + Shift + Up Arrow + T" to get your windows and tabs back.
If the problem continues despite of applying some steps above:
try to restart the IIS Server.

Facebook Debugger needs several refreshes before returning proper og:image value

I've been using the Facebook Debugger to consistently solve a problem with og:image tags that we are using on an AngularJS site. My content editor has to clear caches in FB several times before getting the correct meta to come through. Here is our setup:
We are using a PhantomJS, disk cache enabled look aside for all UA ~ Facebook to properly pass FB requests to our static HTML markup. We have verified (via curl 'http://localhost:9000/path/to/my/page' | grep og:image) that the proper og:image tag is present before trying to share or present a new object to the FB Open Graph
We have to consistently "Fetch new scrape information" 3 - 4 times before FB Debugger pulls the proper image. The debugger returns scrapes in the following way:
-- First fetch: Default og tags before Angular bindings hit.
It's hard to say why this is happening since we haven't tried to share the page previously. We've passed the page into the PhantomJS process and seen the proper og in the returns (in order to cache the return before sharing or heading to FB).
-- Second fetch: Proper og tags filled in with desired image but with the OG Image warning
og:image was not defined, could not be downloaded or was not big enough. Please define a chosen image using the og:image metatag, and use an image that's at least 200x200px and is accessible from Facebook. Image 'XXXXXXX' will be used instead. Consult http://developers.facebook.com/docs/sharing/webmasters/crawler for more troubleshooting tips.
The desired image is 600x337 png (no transparency) so size isn't an issue (and it eventually shows). The fallback image being used instead is the default og:image previous from scrape #1.
-- Third fetch:
OG Image warning is gone and all additional fetches return the proper meta. Sharing works and we can move on.
So while this works, it is a little heavy handed. Clearly we have an issue with FB seeing our default meta, caching that meta, and needing us to clear things out. Before we implement any cache warming in out PhantomJS process, and possibly a POST to the FB API to get the proper scrape markup into Open Graph, can someone answer why the additional 2nd refresh produces the og:image warning and then it goes away? If the proper og:image exists and is correctly sized, why the error?
We looked at this answer, and the comment says to clear our browser cache when using the debugger. We've considered the comment to use multiple browsers but to no avail. We've tried cache-less POSTs using Postman to test this theory as it may be how we cache warm but still see the need for the additional refreshes.

How to completely hide the ExtJS Source Code in browsers inspect element?

I have an EXTJS app and when I look at the source by using browser's inspect element I can see my entire app's source code (except for the server-side code ofcourse.).
I have seen some extjs apps that when inspecting theie source code, all I can see is the app.html page and non of their .js files is discover able by the browser.
I was wondering how I should configure my EXTJS app to make them not viewable inside the browsers "Sources" tab (ie. Chrome's Inspect Element > Sources).
Any help is much appreciated,
The best you can do is to obfuscate your code, as there is no way to stop someone looking at it once its got to the browser.
Even if the browser could hide it somehow, there is nothing stopping a user sniffing the packets on the network etc.

Google App Engine Channel API and Chrome Extensions

Over Christmas I implemented some code to open a channel to my App Engine application using the channel API and it was working fine.
I recently returned to the code and find that it is broken, and the problem seems to lie in talkgadget that the client code is trying to load into a frame.
I took a snapshot of the code returned by /_ah/channel/jsapi on December 21 and I am comparing it to today's code.
When the older version tried to get talkgadget.google.com/talkgadget/d?token=[my-token] it was hardcoded to use http. Sensibly enough, the code was later changed to check the page's protocol in document.location and adapt to cases where https is used. The problem now is that when running in a chrome extension it grabs chrome-extension: as the protocol and naturally the channel fails to open in the extension.
Setting the base of the background page to my appspot URL does not change document.location, although I had some vague notion that it should. (Not sure what the standards say.)
Is there a workaround for this? One thought was to create my own iframe loaded from my site, but then it will nest the actual channel iframe, complicating things.
I wonder if Moishe or someone else on the App Engine team could comment on this. It seems like the this is a bug and the code should take into chrome extensions either by testing for the protocol and searching for a base tag as an alternative, or provide some way to configure this through the javascript object.
Yep, this is a bug. There's a fix submitted, and it's in the process of rolling out to production; it'll probably be out in about a week.
In the meantime, your idea of an iframe embedded in the extension should work.

Prevent Silverlight 3 from caching while debugging

I'm assuming the issue I'm having is related to caching. Code changes I make are not getting picked up when I debug. Most times I get served a previous version of the app. How do I prevent this from happening?
Ctrl+F5 is an easy way to refresh a page and clear the cache of that page at the same time - it may help :)
Try to add to the page that hosts Silverlight application on Page_Load:
Response.Cache.SetExpires(DateTime.Now.AddSeconds(-100));
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Append a "version" querystring to your XAP Url, something like:
http://localhost:1234/ClientBin/my_silverlight_app.xap?v=1.0.287.5361
This will trick the browser (and many web servers) to think that this is a different file. And when the cache problem appears again, increase the number.
If you then want to employ proper caching, do it on the server-side with OutputCache directives.
As far as I see, this seems to be a problem with Firefox - when I used IE8, this didn't happen to me (I realize this may open its own can of worms, but at least for debugging and testing Silverlight, IE is much better)
I have not had any issues with Silverlight assemblies getting cached - you might want to try debugging the HTTP requests that go back and forth, to see if maybe your server is instead returning incorrect information to the browser (e.g. a "not modified" response).
For general no-cache behavior, the only reliable method I have found is to turn off caching in the browser.
For IE, this has been the only reliable option - otherwise, even if proper no-cache headers are sent, certain things are still cached (specifically, dynamically loaded resources which are accessed via Javascript XmlHttpRequest). I have not specifically had issues with Silverlight getting cached when it should not, though - IE has always loaded the latest updates even if cache is enabled.
Firefox has been much more problematic - even when disabling cache, it still sometimes caches XmlHttpRequest-loaded resources. Manually hitting Refresh a few times has been the only solution in such a case. Once again, I have had no issues with Silverlight assembles, even if cache is turned on.
In Firefox, I use the 'web developer' plugin and simply select to 'disable cache'. Works fine.
Firefox 3.5 under Tools has the option for Private Browsing. Click that to disable caching.
Here is how I have done it for flex/flash and silverlight and it works.
Code Behind ASPX or CSHTML
string slUrl = "/ClientBin/MySilverlight.xap";
string filePath = Server.MapPath(slUrl);
FileInfo info = new FileInfo(filePath);
// this will force browser to
// re download file if file was
// updated
slUrl += "?t=" + info.FileWriteTime.Ticks;
ASPX or CSHTML
<embed ....
src="<%= slUrl %>"
..
/>
Trick is you have to change url by adding something after ? and make a new arbitrary random query string or use file write time, and for browser, something?t=1 and something?t=2 are two urls and it will not pickup cache if t changes.
Instead of write time, you can also choose any standard config value or you can even simply hardcode your ASPX or HTML and append something after ? that will force browsers to download silverlight xap file again.
<embed ....
src="/ClientBin/MySilverlight.xap?something-different-each-time"
...
/>

Resources