Issue metadata
Sign in to add a comment
|
Some search engines chrome://favicon/ URLs never get populated. |
||||||||||||||||||||||||
Issue descriptionThis does not seem like a regression, most likely a long standing issue. Repro steps: 1) start with a brand new profile. 2) Visit chrome://settings/searchEngines 3) All search engines should display the default icon, see screenshot. 4) On a new tab, visit search.yahoo.com and wait until the favicon has loaded. 5) Go back to the settings tab and reload, the yahoo favicon should be shown. 6) Repeat 4-5 for search.aol.com, also works as expected. 7) Now repeat 4-5 for www.bing.com and www.ask.com. The icons never show up. The difference I have spotted between the working and non-working cases is the icon URL Not working (multiple path components after the search engine domain) chrome://favicon/size/16@1x/iconurl/https://www.bing.com/s/a/bing_p.ico chrome://favicon/size/16@1x/iconurl/http://sp.ask.com/sh/i/a16/favicon/favicon.ico Working (single path component after search engine domain) chrome://favicon/size/16@1x/iconurl/https://search.yahoo.com/favicon.ico chrome://favicon/size/16@1x/iconurl/http://search.aol.com/favicon.ico So in short my suspicion is that the favicon cache either fails to get populated or fails to return favicon URLs that contain multiple path components http://somewebsite.com/works.ico VS http://somewebsite.com/this/does/not/work.ico
,
Jun 14 2016
,
Oct 10 2016
Issue 646248 has been merged into this issue.
,
Nov 21 2016
Changing the priority to P2 and starting to investigate.
,
Nov 22 2016
Initial findings about favicons shown at chrome://settings/searchEngines (both old Options and MD Settings): The favicon URLs for the default search providers are hardcoded at [1]. On the other hand, the favicon database is populated as the user navigates the web, and it is populated with the actual favicons found in the websites that are visited. It is inevitable that the hard-coded values become obsolete at some point and therefore a default icon is shown in chrome://settings/searchEngines (see example CL [2] updating the URLs for google.com and bing.com and screenshot). I am guessing that similar fixes will (temporarily) fix the favicons for the other search providers, but this seems fragile. I am planning to update the hard-coded favicon URLs for all default search engine providers, for now. Detecting the search engines favicon URLs dynamically so that no URL needs to be hard-coded sounds like a more robust approach, but I have no idea the scale of the changes needed to do that, at this point. [1] https://cs.chromium.org/chromium/src/components/search_engines/prepopulated_engines.json?l=91 [2] https://codereview.chromium.org/2515223004
,
Nov 23 2016
Finished my investigation on what is causing the search engines favicon URLs to be broken. Posted my findings in the doc at [1] so that it is a bit more readable. Document should be visible to everyone with a @chromium account. [1] https://docs.google.com/document/d/1YN4OkEOi5gskFFiTuW8N93kFOdD6MJuEBq4wF__iFJs/edit
,
Nov 23 2016
,
Dec 1 2016
Adding Search component since search engines favicons are semi-related to search. I am hoping to get a word from someone knowledgeable about the overall favicon infrastructure design before digging into a solution myself.
,
Dec 14 2016
,
Jan 23 2017
Un-assigning myself for now, so that others can possibly pick this up (focusing on crbug.com/673825 ).
,
Feb 6 2017
,
Feb 6 2017
,
Feb 7 2017
,
Feb 7 2017
Updating title to be more accurate.
,
Feb 7 2017
,
Feb 8 2017
,
Feb 20 2017
,
Apr 10 2017
Issue 709129 has been merged into this issue.
,
Apr 10 2017
See Issue 709129 -- we are able to populate the favicon on passwords.google.com
,
Apr 11 2017
@tbuckley: The search engines URLs bug, is a bit different than passwords (as explained in depth by comment#6). For Passwords favicons, it is just a matter of populating favicons of URLs that have not been visited by the user. For Search Engines favicons the problem is more involved and specific to Search engines (multiple favicon URLs exist, one from the search engine page itself, one declared in the search declaration http://www.opensearch.org/Specifications/OpenSearch/1.1#The_.22Image.22_element, and they don't match each other). I don't think we should merge those bugs, because the root cause is different.
,
Apr 21 2017
To make sure I understand the issues: 1) We store favicons of websites you've visited but not for search engines you've used, so unless they match we won't be able to show a favicon in the search engine list. This is tracked in this bug. 2) While we sync the favicon URL for search engines and passwords, we won't automatically fetch the favicons so they are blank unless the user has loaded that website. This should be tracked in Issue 709129. For #1, is it possible to start caching search engine favicons in addition to site favicons? How big of an effort would that be? For #2, could we start trying to automatically fetch favicons for search engines / passwords? It seems like passwords.google.com is able to fetch them.
,
Apr 21 2017
1) Not exactly. Will try to further clarify more, since it is a bit complicated: - "We store favicons of websites you've visited", that is correct. The *only* favicon we store is the favicon that is specified in the <head> section of the website. Example for google.com the favicon we store is "https://www.google.com/images/branding/product/ico/googleg_lodp.ico" (see actual_google_com_favicon_url.png). - Now, in the chrome://settings/searchEngines UI (both old and new), when we try to display a favicon for a "default" search engine, we use a hardcoded list of favicons which is outdated, see [1], where it thinks that the favicon URL for google.com is "https://www.google.com/favicon.ico". So we look up our favicon database with this outdated favicon URL as the key, which fails to find an entry in the DB (even if the user has visited google.com it will still fail). - For a "non-default" search engine, when we look up our favicon database, we use as a key the URL specified in the OpenSearch XML description file, which almost always does not match any entry in our favicon database (even if the user has visited those search engines). 2) "While we sync the favicon URL for search engines and passwords..." I have no knowledge on whether we actually do this, so can't comment. [1] https://cs.chromium.org/chromium/src/components/search_engines/prepopulated_engines.json?l=114
,
Apr 21 2017
Sorry if you've already covered this, but why can't we just use the favicon specified in the <head> section of a site for search engines?
,
Apr 21 2017
This might be reasonable for the "default" search engines, but I don't think it is the right fix for the non-default ones (the ones that are picked up by OpenSearch declarations like ). Per my understanding, the most appropriate fix is: - For "default" search engines: 1) Temporary: Update hardcoded values (linked in comment#22) to point to the newer URLs. 2) Longer term: Hardcoded values will almost certainly get obsolete after some time. We should periodically check the actual favicon URL in <head> when the user visits those webpages, and update the database accordingly. - For non-default search engines: When Chrome encounters a new OpenSearch declaration like [1] it registers a new search provider, see TemplateURLFetcher::RequestDelegate::AddSearchProvider at [2]. As part of that logic the favicon specified in the XML file should be fetched and store in the database. [1] https://www.npmjs.com/opensearch.xml [2] https://cs.chromium.org/chromium/src/components/search_engines/template_url_fetcher.cc?l=175
,
Apr 24 2017
@dpapad, is there a reason the non-default search engines proposal wouldn't also work for default search engines? I assume they also have OpenSearch declarations that we could use to detect new favicons. Regardless, for next steps: 1) Actually caching the OpenSearch declaration's favicon sounds like it will solve the problem decently well. 2) As a follow-up, I'd also like to look into fetching the favicon for synced search engines that the user might not have visited yet.
,
May 23 2017
+zea for favicons and sync
,
May 26 2017
There is more context about search engines in particular in Issue 88243
,
Apr 24 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by dbeam@chromium.org
, Apr 29 2016Status: Available (was: Untriaged)