Ubuntu
firefox-3.5 package

Firefox moz-icon://.ext not working

Bug #466567 reported by Tadej Novak
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
Mozilla Firefox 4.0b7
firefox (Ubuntu)
Fix Released
Medium
Unassigned
firefox-3.5 (Ubuntu)
Triaged
Medium
Unassigned
humanity-icon-theme (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

In Kubuntu 9.10 using Firefox the command moz-icon://.ext, where .ext represents file extension does not work. This command should return an icon representing this file type.
In Kubuntu 9.04 this feature works.
After some investigation I found mimetype icons in /usr/share/icons/hicolor/16x16/ on my jaunty installation that are missing in same directory in karmic. I think Firefox loads icons from that location.
This bug is present in Firefox provided by Ubuntu and in Firefox downloaded from mozilla.com, so I think it's not Firefox specific bug.

See original description
Tags: firefox karmic
Revision history for this message
Tadej Novak (ntadej) wrote :

In Kubuntu 9.10 using Firefox the command moz-icon://.ext, where .ext represents file extension does not work. This command should return an icon representing this file type.
In Kubuntu 9.04 this feature works.
After some investigation I found mimetype icons in /usr/share/icons/hicolor/16x16/ on my jaunty installation that are missing in same directory in karmic. I think Firefox loads icons from that location.
This bug is present in Firefox provided by Ubuntu and in Firefox downloaded from mozilla.com, so I think it's not Firefox specific bug.

Revision history for this message
In , flying sheep (flying-sheep) wrote :

my python-script is ready. i reimplemented some moz-icon-parsing and i think that detecting the desktop-enviroment is also already implemented.

just port it, someone, and you are done (oh, and fix one minor TODO)

#! /usr/bin/env python
# -*- coding: utf-8 -*-

from __future__ import print_function
import sys, os
from subprocess import Popen, PIPE

def detectDE():
 if os.environ.get("KDE_FULL_SESSION") == "true":
  return "kde"
 elif os.environ.get("GNOME_DESKTOP_SESSION_ID"):
  return "gnome"
 elif os.environ.get("DISPLAY"):
  return "x"
 return None

url = sys.argv[1] + "?" #the "?" is a bugfix, since string.find() gives back a "-1" when nothing is found.

ext = url[url.find(".") : url.find("?")]

sizeindex = url.find("size=")
if sizeindex == -1: #"size=" not found => no size specified
 size = 16
else:
 sizeend = url.find("?",sizeindex)
 size = int(url[sizeindex+5 : sizeend])

for s in [256,128,64,48,32,22,16]:
 if size <= s:
  sizestr = str(s) + "x" + str(s)

if detectDE() == "kde":
 mime = Popen(["kmimetypefinder", "-f", ext], stdout=PIPE).communicate()[0] #finds mimetype for the extension on kde
 if "\n" in mime: #a two-line-string is only the output if the mimetype is found
  mime = mime[:mime.find("\n")] #remove the accuracy-line
  mime = mime.replace("/","-") # using "-"-mimetypes is more bug-proof
  iconpath = Popen(["kiconfinder", mime], stdout=PIPE).communicate()[0] #finds icon for mimetype
  iconpath = iconpath.replace("\n","") #the line-end is removed
  iconpath = iconpath.replace("48x48", sizestr) #replaces icon size 48×48 with the size specified
 else:
  iconpath = "generic icon path" #to be replaced
 print(iconpath) #the output: you will want to change this to "return iconpath" after making all of this a c++-method ;)

#TODO: Check if requested image size exists and if not, try other sizes

Revision history for this message
In , Tanner-sumo-bugs (tanner-sumo-bugs) wrote :

i see this too. Confirming

Revision history for this message
In , flying sheep (flying-sheep) wrote :

is only in (k|x)ubuntu karmic koala: https://bugs.launchpad.net/ubuntu/+bug/466567

Revision history for this message
flying sheep (flying-sheep) wrote :

filed same bug at bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=521495

Revision history for this message
Ilja Sekler (ilja-sekler-) wrote :

This issue is specific to Humanity* icon sets (package humanity-icon-theme), possibly due to limitations of the moz-icon:// protocol in Firefox and in Thunderbird 3.

Revision history for this message
flying sheep (flying-sheep) wrote :

Why should it be specific to a special iconset?

If anything, it is specific to a special feature the oxygen and humanity (and probably loads of other) themes either have or lack.

With which icon theme does this work for you? Note that this is a Karmic Bug, everything worked for me up to Jaunty!

@Everyone:
Please note that this Bug only covers moz-icon://.ext uris.
moz-icon://stock/* works still fine!

Changed in ubuntu:
status: New → Confirmed
Revision history for this message
Ilja Sekler (ilja-sekler-) wrote :

> With which icon theme does this work for you?

Works at least with gnome and Human icon themes. The most visible difference is that gnome and Human themes contain icons in PNG format in the relevant /usr/share/$ICON_THEME/16x16/mimetypes/ subdirectory, but Humanity has only SVG.

Revision history for this message
flying sheep (flying-sheep) wrote :

that is either not the cause, or on kde there is another one.
for example
/usr/share/icons/oxygen/16x16/mimetypes/image-x-generic.png
exists (and all other mimetype-.pngs) on my pc.

Revision history for this message
Ilja Sekler (ilja-sekler-) wrote :

WFM with oxygen icons on GNOME and current trunk builds of Firefox as well with Thunderbird 3.0.1pre.

Revision history for this message
Ilja Sekler (ilja-sekler-) wrote :

Saving the required icons from the Humanity icon theme as PNG files definitely works around the issue. With the default "Human" theme an Karmic (which includes the Humanity icons), I can see the right icon for application/pdf in the large attachment view in Thunderbird 3 if I save /usr/share/icons/Humanity/mimes/32/x-office-document.svg as ~/.icons/Humanity/mimes/32/x-office-document.png and make a symlink ~/.icons/Humanity/mimes/32/application-pdf.png to this file.

As far as it is unlikely that moz-icon:// would accept SVG soon enough, it could be preferable to be nice to Firefox and Thunderbird and give them what they want. Setting "package" to "humanity-icon-theme".

affects: ubuntu → humanity-icon-theme (Ubuntu)
Revision history for this message
Vish (vish) wrote :

We are not going to convert all our MIME icons to png , just because a single app is not able to handle the svg.

It is a problem in the app and not the icon theme.

Changed in humanity-icon-theme (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Vish (vish) wrote :

Firefox is able to use the svg icons in the toolbars and other locations.
So, it needs to be fixed in firefox and not workaround the problem by asking the icon theme to change its icon formats.

Revision history for this message
Tadej Novak (ntadej) wrote :

What about using other icon themes. Firefox successfully uses Oxygen icons as back/forward/refresh if this theme is selected. And Oxygen already has .png mime icons.

Revision history for this message
In , Reed Loden (reed) wrote :

*** Bug 528382 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Reed Loden (reed) wrote :

Comment #0 is very hard to follow. Check the launchpad bug or my bug 528382.

Revision history for this message
In , Reed Loden (reed) wrote :

If this only happens after an upgrade to Ubuntu 9.10, I guess it's not really a regression on Firefox's end.

Revision history for this message
In , Ilja Sekler (ilja-sekler-) wrote :

The initial Firefox 3.0 release behaves exactly the same, so likely the default SVG-only icon theme on Ubuntu 9.10 just exposed for the first time some issues or of moz-icon:// protocol.

Actually, it is enough to change the filename extension of SVG icons from .svg to .png (e.g. put symlinks into ~/.icons/Humanity/mimes/$ICON_SIZE/ with .png as extension) to make them "work".

Revision history for this message
In , flying sheep (flying-sheep) wrote :

remember: this is not only about svg.
i have a kde desktop and use the oxygen icons. every mime icon is a png-picture and the mime icons do not work in firefox.

furthermore i did not uprade, my kubuntu 9.10 is freshly installed!

tu sum it up: the last two comments are misleading, since they only refer to gnome desktops, not kde.

Revision history for this message
In , Beltzner (beltzner) wrote :

So this is or isn't a Firefox regression?

re comment 8; flying sheep, I think what Reed is saying is that something in Ubuntu 9.10 may have caused this.

Revision history for this message
Micah Gersten (micahg) wrote :

Thank you for reporting this. I'm marking this triaged as we have an upstream bug. Please report any other bugs you may find.

affects: firefox (Ubuntu) → firefox-3.5 (Ubuntu)
Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
In , Ilja Sekler (ilja-sekler-) wrote :

(In reply to comment #9)
> So this is or isn't a Firefox regression?

No. But the problem on GNOME seems to live on the Firefox end, so this should be fixed in Firefox. Unsure about the problem on KDE, it is IMHO different and probably a KDE (or even KDE and Ubuntu-specific) bug.

So said, I apologize for the mess I caused asking Reed to dupe his bug 528382 to this one. Don't know whether it would be better to undupe bug 528382 and to give this one a better summary and description or to continue in this bug despite the original intention of the reporter.

Revision history for this message
flying sheep (flying-sheep) wrote :

i use a kde desktop, the oxygen icon theme (png!) and the mime icons don’t work for me.

so this bug happens in two cases: using .svg-icon themes on gnome or using anything on kde!

Revision history for this message
Ilja Sekler (ilja-sekler-) wrote :

> so this bug happens in two cases: using .svg-icon themes on gnome
> or using anything on kde!

I apologize for the mess. The issues on GNOME and on KDE are unrelated IMHO.

To finish with the issue on GNOME in this bug, I suggest the following per-user
workaround for the Humanity icon theme:

#!/bin/bash

ISOURCE=/usr/share/icons/
ITHEME=Humanity

for size in 16 22 24 32 48;
do
  mkdir -p $HOME/.icons/$ITHEME/mimes/$size;
  for file in $ISOURCE/$ITHEME/mimes/$size/*.svg;
    do ln -s $file $HOME/.icons/$ITHEME/mimes/$size/`basename $file`.png;
  done;
done;

It turns out to be, that it is not required to convert SVG icons to PNG format:
changing the filename extension to .png is sufficient.

Revision history for this message
Ilja Sekler (ilja-sekler-) wrote :

Oops... This:

ln -s $file $HOME/.icons/$ITHEME/mimes/$size/`basename $file`.png;

must be on a single line or the line break must be escaped.

Revision history for this message
Ilja Sekler (ilja-sekler-) wrote :

> ln -s $file $HOME/.icons/$ITHEME/mimes/$size/`basename $file`.png;

*Arrgghh* once again the fixed script:

#!/bin/bash

ISOURCE=/usr/share/icons/
ITHEME=Humanity

for size in 16 22 24 32 48;
do
  mkdir -p $HOME/.icons/$ITHEME/mimes/$size;
  for file in $ISOURCE/$ITHEME/mimes/$size/*.svg;
  do
    ln -s $file $HOME/.icons/$ITHEME/mimes/$size/`basename \
    $file .svg`.png;
  done;
done;

of course... My deepest apologies for the bugspam!

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unknown → Confirmed
Revision history for this message
In , Dveditz (dveditz) wrote :

Don't see how minor UI polish can possibly be a blocker for security updates.

Revision history for this message
In , Joe-drew (joe-drew) wrote :

OK, let's call this a bug with SVG icons. flying sheep: could you please file a separate bug for your issue, and we will track it down there?

There is absolutely no way this should block.

Revision history for this message
In , flying sheep (flying-sheep) wrote :

Joe, this is my bug. The Gnome Users just found out that they have a similar issue, too and discussed it here.

Revision history for this message
In , flying sheep (flying-sheep) wrote :

I made a new Bug report. Could somebody with kde please confirm Bug 532362, since for me, this discussion was a waste of time.

don’t get me wrong, i’m glad you tracked down your .svg-bug here, but initially i reported this and wanted my problem tracked down ;)

Revision history for this message
In , Joe-drew (joe-drew) wrote :

*** Bug 535549 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Nils Maier (testnutzer123) wrote :

Created an attachment (id=418531)
v1 central, Fix moz-icon under gnome by using gtk functions

Current patch uses gtk_icon_theme_* which replaces the libgnomeui stuff since some time.
See: http://live.gnome.org/LibgnomeMustDie

A lot of stuff already depends on gtk 2.4+, so depending on it shouldn't be a problem here.

Tested to work under Ubuntu karmic 9.10 x86.

Revision history for this message
In , Joe-drew (joe-drew) wrote :

(From update of attachment 418531)
Is it possible to add a test on this? Are there any icons that ship with most default gtk themes in SVG format?

Revision history for this message
In , Nils Maier (testnutzer123) wrote :

Created an attachment (id=422104)
v0, xpshell-tests

Some xpcshell tests.

The test will try to open channels for various pre-defined file icons at different sizes.
All tests are expected to succeed.

Some troubles, however:
* On *nix (at least on Ubuntu karmic x86) xpcshell seg faults in exit_handlers after running these tests, no matter if my icon channel patch was applied before or not.
Stack is like this:
#0 0x432dfa40 in ?? ()
#1 0x41758afc in IA__g_hash_table_foreach (hash_table=0x920d720, func=0x42e13460, user_data=0xbfe22984) at /build/buildd/glib2.0-2.22.3/glib/ghash.c:1211
#2 0x42e17333 in ORBit_POA_deactivate () from /usr/lib/libORBit-2.so.0
#3 0x42e17594 in ?? () from /usr/lib/libORBit-2.so.0
#4 0x42e1782d in PortableServer_POA_destroy () from /usr/lib/libORBit-2.so.0
#5 0x42e01c06 in CORBA_ORB_shutdown () from /usr/lib/libORBit-2.so.0
#6 0x42e01d7f in CORBA_ORB_destroy () from /usr/lib/libORBit-2.so.0
#7 0x42e0355f in ?? () from /usr/lib/libORBit-2.so.0
#8 0x4124c05f in __run_exit_handlers (status=153158016, listp=0x4135e304, run_list_atexit=true) at exit.c:78
#9 0x4124c0cf in *__GI_exit (status=0) at exit.c:100
#10 0x41233b5e in __libc_start_main (main=0x804baf6 <main>, argc=18, ubp_av=0xbfe22bc4, init=0x8051c10 <__libc_csu_init>, fini=0x8051c00 <__libc_csu_fini>, rtld_fini=0x4000dd20 <_dl_fini>,
    stack_end=0xbfe22bbc) at libc-start.c:252
#11 0x0804a541 in _start () at ../sysdeps/i386/elf/start.S:119

Any ideas about that?

* Cannot test on Mac, as I do not own a Mac.

Test work fine under Win32. Win32 already returns an icon, always.

(In reply to comment #17)
> (From update of attachment 418531 [details])
> Is it possible to add a test on this? Are there any icons that ship with most
> default gtk themes in SVG format?

I don't think you can really make any assumptions about the system/distro in place.
Hence the more general tests.

Revision history for this message
In , Reed Loden (reed) wrote :

(From update of attachment 418531)
>+#if GTK_CHECK_VERSION(2,4,0)

Why do we need such a check here at all? configure.in has GTK2_VERSION=2.10.0 as the minimum version.

Revision history for this message
In , Nils Maier (testnutzer123) wrote :

(In reply to comment #19)
> (From update of attachment 418531 [details])
> >+#if GTK_CHECK_VERSION(2,4,0)
>
> Why do we need such a check here at all? configure.in has GTK2_VERSION=2.10.0
> as the minimum version.

There are a couple of such checks in already. I didn't know if the configure check is considered enough, so I did stick with the code style already there and added one such check myself.

If these checks are considered "obsolete" I can easily remove the one I added and the others as well.

Revision history for this message
In , Mozilla (mozilla) wrote :

(In reply to comment #20)
> (In reply to comment #19)
> > (From update of attachment 418531 [details] [details])
> > >+#if GTK_CHECK_VERSION(2,4,0)
> >
> > Why do we need such a check here at all? configure.in has GTK2_VERSION=2.10.0
> > as the minimum version.
>
> There are a couple of such checks in already. I didn't know if the configure
> check is considered enough, so I did stick with the code style already there
> and added one such check myself.

IMO the check could make sense still. The reasons for requiring 2.10 are for example the new print dialog. In case someone wants to ship anything based on mozilla and don't need that it's still better to have checks for the other (older) stuff. But that's only my opinion.

Revision history for this message
In , Nils Maier (testnutzer123) wrote :

Any idea about the crashing test exit (comment #18)?
If not, maybe implement this as mochitests instead of xpcshell ones? Or what else?

Does this require super-review, and if yes could you point me at the best sreviewer for this type of bug?

Revision history for this message
In , Dao (dao) wrote :

http://hg.mozilla.org/mozilla-central/rev/e63da1dc90b6
http://hg.mozilla.org/mozilla-central/rev/5fda39cd703c

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Confirmed → Fix Released
Revision history for this message
Micah Gersten (micahg) wrote :

Adding unversioned firefox package to track the fix in Lucid+

Changed in firefox:
milestone: none → 4.0
Changed in firefox (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Medium
Revision history for this message
In , Kim (kim-h) wrote :

With this fixed, is the "height < 256 && width < 256" checks still really necessary in?:
http://hg.mozilla.org/mozilla-central/file/d0d3ac2ce08c/modules/libpr0n/decoders/icon/gtk/nsIconChannel.cpp#l102

I think the comparator might be wrong too, should I file a new bug for that if the checks should stay in?

Revision history for this message
Micah Gersten (micahg) wrote :

This is fixed in Natty now with Firefox 4.0b7. Please report any other issues you may find.

Changed in firefox (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Ilja Sekler (ilja-sekler-) wrote :

> This is fixed in Natty now with Firefox 4.0b7. Please report any
> other issues you may find.

While true for Firefox 4 on top of Gecko 2.0, this bug is still valid for Thunderbird 3.1 on top of Gecko 1.9.2. It is even much more prominent there as there are no attachment icons in Thunderbird with the default Ubuntu icon theme.

How would you like to proceed for Natty? Do nothing and hope that Thunderbird releases a next major version based on Gecko 2.0 till then? Apply the patch <https://bugzilla.mozilla.org/attachment.cgi?id=418531> (this is what I do locally for my private Thunderbird builds)?

Do you wish to track the issue for the thunderbird (Ubuntu) in a separate bug?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.