The Mozilla distribution should add the file type icons in chrome/icons/default/. particularly it should include the following: html-file.ico xml-file.ico xhtml-file.ico xul-file.ico jpg-file.ico gif-file.ico png-file.ico mng-file.ico bmp-file.ico Furthermore, checking the file type in Prefs|Advanced|System should associate these icon files to the extension. For example, HKEY_CLASSES_ROOT\MozillaHTML\DefaultIcon Default="C:\Program Files\mozilla.org\Mozilla\chrome\icons\default\html-file.ico,0" The installer should also associate these icons if the user chose to make Mozilla the default browser. Note that HTML files should be associated with html-file.ico and not main-window.ico. This would allow vendors the flexibility to use a different ico file for both. For an example of an icon pack that contains file type icons, please take a look at the Classic Icons found at http://mozillako.hypermart.net/iconpacks/
dupe of bug 159861 or other way around. confirming because of good technical descrip.
Let me add that this is not really an installer issue. When users choose to make Mozilla the default browser during install, the installer simply sets the prefs. So the problem lies with what Mozilla does when the prefs are set (and unset). Although it is not an install issue, the Uninstall program needs to remove these keys too, since they may have been created after install.
--> Preferences: Backend. Reassign.
*** Bug 159861 has been marked as a duplicate of this bug. ***
This is a regression. It was working until the new icons were checked in.
Reading between the lines here, it sounds like somebody broke the association to file icons. This has absolutely nothing whatsoever to do with the backend preferences library. Back to Browser General for triage...
No, this is not a regression, and nobody broke the association to file icons. Mozilla has never wrote a "DefaultIcon" key in the registry. If Windows detects that "DefaultIcon" is null, it automatically uses the icon with the lowest resource number in the exe file. Which, in this case, was the blue gecko (a.k.a. SpermZilla). Furthermore, I did the following experiment: 1) Install Moz on a clean machine using the zip builds (not installer). This means the machine has no registry entries for Moz whatsoever. 2) Go to Prefs|Advanced|System and check all. Although for this example it is enough to just tick 'HTML Documents'. 3) Open Regedit. You will find that HKEY_CLASSES_ROOT\MozillaHTML has been created. 4) Open the key and you will find that a "shell" key has been created but not "DefaultIcon". That's why I think it's a Prefs issue.
*** This bug has been marked as a duplicate of 99380 ***
Matti, although from the outset that bug does seem similar to this, the resulting discussion has been very different. The objective of that bug seems to have shifted onto deciding on which icons to include. I don't care about those discussions. I'd rather talk about how to get those icons to work. With your permission, you being the default owner, I'd like to reopen this bug. It provides a cleaner workspace to discuss possible implementations of the fix.
It's possible that it's shifted but it's the correct bug. We have many dupes and bugs related to icons. The problem ist not how to implement it, the icons are the problem ! The main problem is bug 28028. We can't implement this if we have no good icons. And we will not implement something if we have no good default icons.