New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 760009 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Feature



Sign in to add a comment

Website favicon not used as desktop shortcut icon (Chrome icon used instead)

Project Member Reported by jtruschka@google.com, Aug 29 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce the problem:
1. Select URL in the address bar
2. Drag and drop the URL onto your Windows 10 desktop. 

What is the expected behavior?
The desktop shortcut would use the favicon of the website (if there is a favicon).

What went wrong?
The desktop shortcut always uses the generic Chrome icon.

Did this work before? No 

Chrome version: 60.0.3112.113  Channel: stable
OS Version: 10.0
Flash Version: 

The browser is much more than just another application. There are plenties of shortcuts that are being stored, all opening the browser but different websites and web apps. It would greatly enhance user's orientation on the desktop, if the shortcuts used the favicon. (I believe MS IE used to support this feature.)
 
Labels: -Type-Bug Needs-Triage-M60 M-62 Type-Feature
Status: Untriaged (was: Unconfirmed)
As per the above description, marking this as a Feature Request and changing the status to Untriaged, as the reporter wants the favicon icon of the website on the desktop on dragging and dropping the url.

Thanks..
Components: -UI Internals>PlatformIntegration
Sounds like a platform integration request.

FWIW, I have no idea if favicons come in the same sizes as Windows desktop icons.

Labels: -Pri-2 -Arch-x86_64 -M-62 -Needs-Triage-M60 Pri-3
Owner: rpop@chromium.org
Status: Available (was: Untriaged)
Initial triage discussion:

Supporting this in Chrome is plausible. 

The Internet Shortcut files (*.url) support specifying a URL to refer to a favicon. Sites would need to make sure they have a Windows icon file available (*.ico) as the favicon and the Windows Shell will pick it up.

Sending to rpop@ for initial awareness and feature triage.
 Issue 827846  has been merged into this issue.
Also affects Linux.

The side effect is that this Chromium shortcuts hard to distinguish one from each other.

The icon data is actually in the shortcut, but it doesn't work. This looks rather like a bug, not a feature as mentioned in the panel.

Comment 6 by rpop@chromium.org, Apr 4 2018

Cc: groby@chromium.org rpop@chromium.org bettes@chromium.org
Owner: markchang@chromium.org
Status: Assigned (was: Available)
+Mark, but I think we should definitely look into it. My desktop is a horrifying grid of identical Chrome icons right this minute.

It sounds like the hard part is what to do when the best favicon is 16x16 and the windows app icon is much bigger than that. 
robliao@ what happens if 
a) the web site does not have an ico file available?
b) there is no network connection so the windows shell cannot reach the site?
Responding to #7
Both a) and b) resolve to the same failure case.
If a website does not have an ICO available, the icon of the original association will display (generally the default browser).

The specified details are available here:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776784(v=vs.85).aspx

Playing around with the format, the shell is a little finicky on when it decides to pick up the new icon and when it doesn't. I'm guessing there might be an additional shell notification required to kick start the machinery.
Got it. Is this something we can implement behind a flag to try out? As rpop@ noted, I can't tell if this will be an improvement or not. Concerns that I'd like to try in real life:

* what it feels like to have *all* my icons that used to be chrome turn into favicons
* what it feels like to have some icons change and some not (due to network or missing favicon)?



Cc: robliao@chromium.org
Adding rob back because he made the mistake of answering questions :) :) :P
Owner: lgrey@chromium.org
Leonard, we can close this out as it is launched (and will be overridden with MD refresh), correct?
Cc: lgrey@chromium.org
Owner: markchang@chromium.org
Assuming c#13 was meant for one of the Mac RTL bugs? I'm probably not the right person for a Windows issue :)

Sign in to add a comment