User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6; .NET CLR 3.5.20404) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007092312 Webrunner/0.7 I followed the instructions for creating a web application bundle for WebRunner, and when I test my bundle WebRunner doesn't use the icon I specified in the ini file. I have taken a look at some other bundles that do work, and the only difference seems to be that they include xpm and icns files (for Linux and OS X support respectively) as well as the ico. I can't see where it's stated what file formats are required for the icon. If a file is required for every supported OS, wouldn't it make more sense to just require a platform-independent file format like png? Reproducible: Always Steps to Reproduce: 1. 2. 3.

(In reply to comment #0) > If a file is required for every supported OS, wouldn't it make more sense to > just require a platform-independent file format like png? Someday maybe, but currently, the Mozilla platform doesn't support PNG as a universal window image format. The format is dictated by the OS: IOC for Windows, ICNS for Mac and XPM for Linux Also, the OS has format restrictions for what type of image can be used on desktops, docks and OS application menus. A more reasonable approach might be to use PNG, but then convert to the OS specific format.

I've created this extension as a place to put operating system-specific code for testing in Prism. The idea is to get this code into trunk eventually, but this might be difficult until after the FF3 release. The current version contains only an encoder for ICO files. This can be used to generate ICO files from PNGs and other portable formats for which Mozilla has a decoder. This is part of the fix for this bug. The current version is rough. I've included conditional compilation for both frozen and internal linkage since I don't want to use libxul in my debug build (linking toolkit takes too long). I haven't included conditional compilation for non-Windows boxes yet so this version only works on Windows. The next step is to make the extension platform-independent and write encoders for XPM (Linux) and ICNS (Mac).

This is a total hack but it serves its purpose, which is testing that we can generate platform-specific icons from platform-independent image formats. I'll clean this up once I've got the icon generation code working on Mac and Linux as well. Currently it only works on Windows and you have to have the osintegration extension installed as well as my version of dolske's patch from bug 389273.

(In reply to comment #2) > Someday maybe, but currently, the Mozilla platform doesn't support PNG as a > universal window image format. The format is dictated by the OS: ICO for > Windows, ICNS for Mac and XPM for Linux Does Linux really require XPM? This came up in bug 404402, too. Given that 1.9 requires a relatively modern platform baseline, it would be nice to avoid dealing with the crufy old format.

(In reply to comment #5) > (In reply to comment #2) > > > Someday maybe, but currently, the Mozilla platform doesn't support PNG as a > > universal window image format. The format is dictated by the OS: ICO for > > Windows, ICNS for Mac and XPM for Linux > > Does Linux really require XPM? This came up in bug 404402, too. Given that 1.9 > requires a relatively modern platform baseline, it would be nice to avoid > dealing with the crufy old format. > Yeah, see SetIcon here: http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp#1330 SetIcon is passed a name (but not extension). It then forces a ".xpm" extension (and a "16.xpm" alternative too) and searches for the file.

I'm all for testing ".png" instead of ".xpm" if the GTK window will support it. Unfortunately, Windows still requires ICO, but I wonder if we could use this encoder to convert a PNG to and ICO on the fly. Then we could get rid of the multiple formats.

Converting PNG to ico on the fly sounds like a good solution to me but I'm not an expert on C programming.

Fixed as part of bug 400164