Closed Bug 214798 Opened 21 years ago Closed 21 years ago

Mozilla should NOT be associated with the .ICO filetype

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: SkewerMZ, Assigned: jag+mozilla)

References

Details

Currently Mozilla offers to associate itself with the .ICO filetype. (I can't
get it to actually change the association for some reason... if I can verify
this problem on a clean profile I'll report that separately.) I fail to see the
point of doing this, especially on the Windows platform. Mozilla is only capable
of displaying one of the pictures in the icon, when just looking at the icon in
the shell allows you to see all the views. Furthermore it would ironically be
more correct for us to assign ICO files to MSPaint because there is so little
Mozilla can do with them. And it will require more work to get ICO to display
properly when bug 99380 is checked in because we must programmatically set up
the ICO association so the icon's actual content is displayed as its icon (which
is the proper behavior). Since I have yet to see Mozilla successfully associate
itself with ICO I can't verify what it does to the icons of .ICO files right now.

There may be better reasons to associate ICO in non-Windows environments but
I'll leave that to users of those OS to decide if it's wanted.
bug 131106 ?
> when just looking at the icon in the shell allows you to see all the views

How? I've never seen this.

> Mozilla is only capable of displaying one of the pictures in the icon

I have thought about this before, and think that we should, when displaying an
.ico alone, show all the device icons and list their resolution and dimensions
next to it, along with an (XP) for XP images. This could be done the same way as
we handle zooming on stand-alone images.

Considering that the icons in bug 99380 didn't look right on my browser in
Windows XP (the alpha colors were black), along with what you mentioned before,
I would have to agree that our handling of icons needs improvement.

I have no opinion whether or not we should allow associations, but I wouldn't be
against not offering the association until icons looked correct and showed all
device types.

> Furthermore it would ironically be more correct for us to assign ICO files to
> MSPaint because there is so little Mozilla can do with them

Another option would be for us to allow people to add and remove an additional
item in the context menu that says "View" or "View With Mozilla" through a shell
extension. Sometimes, that would be a better option than being the primary
application for a file type.

> And it will require more work to get ICO to display
> properly when bug 99380 is checked in because we must programmatically set up
> the ICO association so the icon's actual content is displayed as its icon
>(which is the proper behavior).

Probably not a big deal. Just look at what your favorite icon editor does in the
registry to see how to do it. Still, offering to add "View in Mozilla" to the
context menu when you right click on the icon or something of that nature seems
a lot more reasonable to me.
bug 131106 appears to be a seperate issue, but its related. Its about installer
automatically grabbing extensions. I'm going to comment in that bug that this
bug is related.
The big question is, why associate with ICO at all? It's silly--we have nothing
valuable to offer the ICO format, all Mozilla can do is display them as
favicons. If our browser was needed as a viewer that would be a different story
(and this is why I think there might be a tiny bit of excuse on non-Win
platforms) but you can easily view the icon in the shell window, provided nobody
has improperly messed with the display of the icon's content.
If we allowed a user to quickly view all the device images, that would be
something. We display them though, so its like any other image. All we have to
do is figure out how to make Mozilla refrain from replacing the icon files'
images. Personally, after thinking, I think we should disable the ability to
make this association until that is fixed. That's a major flaw in the
implementation.

I associated with .ico and it worked for me, but it did replace the image for
the icons with resource mozilla.exe,0 or image-file.ico if I put it in
[chrome]/icons/default. See:
http://bugzilla.mozilla.org/show_bug.cgi?id=99380#c148
> All we have to
> do is figure out how to make Mozilla refrain from replacing the icon files'
> images. Personally, after thinking, I think we should disable the ability to
> make this association until that is fixed.

Brian: and I think that's what my patch, submitted to bug #99380, does.  The
code for mucking about with the registry is rather advanced C++, which TBH is
over my head, so I'll not be trying to make a patch to actually get that proper
.ico association.
That's simple C++ for me. I'm afraid if it doesn't go in now, it never will.
Unassociating .ico will also have to mean a change to the UI (have you done
this?). Its easier to just do the C++ (actually, its probably C). Once your
patches pass my review, I'll add that code in myself. Therefore, don't go
through much trouble disabling .ico since I'll probably reenable it when I add
in the code.

This bug should be wontfix or the summary should be changed to "Don't change
icon associated with .ico files"
Fix for the overriding of icons image will be in bug 216187
Until/unless Mozilla is capable of viewing AND editing all images within a .ICO
file it is stupid and worthless to try to associate with ICO. Why would *anyone*
desire to open a .ICO file in Mozilla? I've still heard no response to that
question.

A vote for this bug is a vote against bug 216187.
Just because you might not want .ico files associated doesn't mean some people
won't. Most viewers don't show all device images. That would be a bonus, but
sure isn't a requirement.

What's probably going to happen is that everything you complain about I'm going
to fix then eventually this bug will be marked WONTFIX. Feel free to keep it
open now as a method of protest for the problems with .ico images. There are
others, like I've noticed that the icons we created in bug 99380 didn't look
right, but that's probably because of the Alpha Channel issue that's been fixed.

Filed a bug on the device images: bug 216274
Found a bug for alpha images:
Blocks: icons
It's the new Bugzilla game... "Dodge the Question."

  Why would *anyone* desire to open a .ICO file in Mozilla?
Erm, he didn't dodge the question.  People might want to open a .ico in Mozilla
if Mozilla handled them better, and showed all an icon's available sizes and
color depths.  Just because it doesn't right now doesn't mean it never will.  At
the moment, it's probably best of the option is dropped (as the support for MNG
was) because Mozilla doesn't really do much with an icon (displays a 16x16!)
I would find drivers' complaints of bloat from supporting MNG more convincing if
utterly stupid things like ICO association (and Chatzilla) were pulled.
This looks like wontfix, because the issues are covered by bug 216187 (fixed),
bug 99380 and bug 131106.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Verified... This bug had merit until those issues were fixed, but now its moot.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.