ia32-libs missing 32-bit gnome libraries needed for gtk stock icons

Created an attachment (id=287564)
nightly screeshot

Tim, can you hunt down a one-day regression range, by any chance?

has icons:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a9pre) Gecko/2007092204 Minefield/3.0a9pre

no icons:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a9pre) Gecko/2007092304 Minefield/3.0a9pre

WFM with 32‑bit userland on Debian testing.
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a9pre) Gecko/2007110604 Minefield/3.0a9pre

Checkins in that range:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-09-22+02&maxdate=2007-09-23+06&cvsroot=%2Fcvsroot

Looks like this is when we switched to stock icons in bug 396992....

I wonder if there is a problem with 64-bit GTK. 32-bit works fine so I don't think its us...

nice to fix, but not a blocker.

Tim, do you have stock icons in other places? (prefwindow, dialogs, etc)

I see winstripe icons in Prefs, Toolbar, Addons and other places such as Bookmark manager.

What about the GTK-style icons on buttons in dialogs etc? If stock icons just plain don't work on x64, we should move this to Core and fix that.

(From update of attachment 287564)
The "OK" button in the about dialog should have a stock icon. Obviously it's not there.

Is this a regression? Or were we not using stock icons in Fx2?

We weren't using them for FTP listings. Or do you mean in general?

I mean in general, as in the OK button in the about dialog.

There are plans to use stock icons in the main nav toolbar.

renominating based on comment 14. At that point, the browser UI will be unusable without stock icons...

But is this really us and not faulty x64 GTK? I can't find anything in nsIconChannel.cpp that stands out as not 64-bit safe.

If you're asking me, I have no idea.

Do users really care why exactly it is that their browser has no more icons on the main toolbar after an update? If it's not us, we shouldn't be using stock icons there.

http://mxr.mozilla.org/seamonkey/source/modules/libpr0n/decoders/icon/gtk/nsIconChannel.cpp

Can anyone here who has an x64 machine add some debug symbols or printf's to their build and say exactly which path the icon rendering is taking? It might be returning one of the error codes.

This is a typical stock icon URL that can be used for testing:
moz-icon://stock/gtk-go-back?size=toolbar

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b2pre) Gecko/2007111005 Minefield/3.0b2pre
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre) Gecko/2007110804 Minefield/3.0b2pre

FYI I have no problems with neither my self build (x86_64) nor the nightly build (i686) on Fedora7.

Plusing and setting to P3. Please adjust if you thing this is wrong

Comment #19 said that stock icons worked on their 64 bit build, so I'm not sure if it is our problem. Can anyone else with 64-bit confirm the problem or not?

(In reply to comment #21)
> Comment #19 said that stock icons worked on their 64 bit build, so I'm not sure
> if it is our problem. Can anyone else with 64-bit confirm the problem or not?

I see the same issue as the reporter. With my own 64bit builds, I have stock icons but I don't see them with the nightly builds (i686).

I'm using Ubuntu 7.10 x86_64. Ubuntu has a different way of packaging things for 32bit, like having one big ia32-libs package containing all 32bits libraries. There may be missing things in the 32bit packages.

If I try to open the moz-icon://stock/gtk-go-back?size=toolbar image in a nightly build, I'm getting a "Firefox doesn't know how to open this address, because the protocol (moz-icon) isn't associated with any program." message.

(In reply to comment #22)
> With my own 64bit builds, I have stock
> icons but I don't see them with the nightly builds (i686).

What about release builds? Firefox 2?

Note that we're now using stock icons for the navigation toolbar, which means that we should get much more feedback if this is a widespread problem.

here's the issue:

ldd components/libimgicon.so |grep "not found"
        libgnomeui-2.so.0 => not found
        libbonoboui-2.so.0 => not found
        libgnome-keyring.so.0 => not found
        libgnome-2.so.0 => not found
        libgnomevfs-2.so.0 => not found

The ia32-libs Ubuntu package does not contains all of the needed 32bit gnome libraries for accessing the stock icons. I can also confirm that I see no icons in the toolbar with the latest nightly.

GTK+ stock icon support should not depend on Gnome libraries anyway. 32bit nightly build with cairo-gtk2 enabled build with no Gnome support doesn't show toolbar icons here.

Sounds like Ubuntu ships a broken 32-bit gnome environment; this bug should get
filed upstream with them.

(In reply to comment #27)
> Sounds like Ubuntu ships a broken 32-bit gnome environment; this bug should get
> filed upstream with them.
>

Does that mean GTK+ stock icon support depends on Gnome libraries? Thats not really a wise decision. Its just lots of extra dependencies just to display icons.

> Does that mean GTK+ stock icon support depends on Gnome libraries?

Yes. On gnome_icon_lookup and gnome_icon_theme_lookup_icon to be exact.

If you know a way to achieve equivalent functionality without the GNOME dependency, please do tell!

I just filed Ubuntu launchpad #162993 (https://launchpad.net/bugs/162993) on this issue.

(In reply to comment #29)
> > Does that mean GTK+ stock icon support depends on Gnome libraries?
>
> Yes. On gnome_icon_lookup and gnome_icon_theme_lookup_icon to be exact.
>
> If you know a way to achieve equivalent functionality without the GNOME
> dependency, please do tell!

Well thats gonna be fun for distributions, I'll check with GTK+ guys if there is a GTK+ way to do this.

> If you know a way to achieve equivalent functionality without the GNOME
> dependency, please do tell!

Wouldn't it be possible to steal it from libgnomeui without too much work? I
had a look at the GTK+ file chooser, and they pretty much re-implement it
internally[1]. Apparently, other applications such as gedit are planning taking
this road as well[2].

If it's too much trouble, now that stock icons are used in the navigation bar
by default (i.e. now that gnomestripe has been committed to the trunk), I think
it would be nicer if a stub moz-icon:// handler showing some default "missing"
icon was implemented for the one of us not having gnome installed: the
interface would feel less broken this way, and users could quickly spot the
problem.

--
[1]http://svn.gnome.org/viewvc/gtk%2B/trun/gtk/gtkfilechooserdefault.c?view=mar$
[2]http://blogs.gnome.org/pbor/2007/09/24/delivering-the-killing-blow-to-libgno$

(In reply to comment #32)
> [1]http://svn.gnome.org/viewvc/gtk%2B/trun/gtk/gtkfilechooserdefault.c?view=mar$

http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkfilechooserdefault.c?view=markup

> [2]http://blogs.gnome.org/pbor/2007/09/24/delivering-the-killing-blow-to-libgno$

http://blogs.gnome.org/pbor/2007/09/24/delivering-the-killing-blow-to-libgnome/

I saw this on Fedora 8 x86_64. The previous/next/home icons were all missing. syp on irc.mozilla.org pointed me to this bug.

I found the libraries were missing as per comment 25. It was fixed by doing:

# yum install libgnomeui.i386

Then I needed to restart minefield and create a new profile before the icons returned.

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

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

(In reply to comment #23)
> What about Firefox 2?
>
Firefox 2 uses also some few stock icons on buttons in the pref panel (toolkit/themes/gnomestripe/global/button.css. These are also missig when MOZ_ENABLE_GNOMUI is not defined or libgnomui.so is not present. However, as you have still the text on the buttons, it is not so obvious.
In principle the usage of GNOME stock icons pulls in an unconditional dependency on libgnomeui, thus building with disable-gnomeui should be removed from configure.in. But as a workaround we could also build winstripe for those who don't want to pull in libgnomeui. This would however not be a solution for distros who don't pack libgnomeui.so in their libs.

Created an attachment (id=291129)
This would build winstripe if libgnomeui isn't there

As a workaround use winstripe theme if libgnomeui isn't present. This patch doesn't touch toolkit/themes/gnomestripe/global/global.css and button.css cause those look broken with winstripe and the corresponding text is still displayed. This helps only when building yourself - not helpful for distros omitting libgnomeui.

(From update of attachment 291129)
If we can't come up with a better fix by b2, we might should take a wallpaper like this. :/

Requesting r?gavin/mconnor for normal browser/toolkit review (whoever gets to it first) and r?roc to see if he thinks this is the best fix for now until we figure something else out to deal with this.

(From update of attachment 291702)
Can you file a new bug for this? Also, http://mxr.mozilla.org/firefox/source/toolkit/library/libxul-config.mk#279 needs to be fixed, too.

Created an attachment (id=291734)
Patch 2 using ifdefs

(In reply to comment #82)
> I don't know if this compiles w/o libgnomeui
Here is a revision of your patch: it now compiles here on a gtk2+ system without libgnomeui (no headers nor lib), and the moz-icon:// protocol is present in the resulting built.

It's hard for me to tell if it works as expected though: I seems to only get
"missing icons" instead of the expected stock icons (such as gtk-go-back) though the moz-icon handler, while I get a few "Gtk-WARNING **: Error loading theme icon '' for stock: Icon '' not present in theme" on the console.
Looking at comment #83, I wonder if it's not related to me screwing the xul.

Created an attachment (id=291776)
enable icon decoder in non gnomui builds would belong to patch2

(In reply to comment #84)
> Created an attachment (id=291734) [details]
> Patch 2 using ifdefs

I need in addition a patch for configure, otherwise icon decoder gets stripped and not built at all with disable-gnomeui and the icons are missing.

> while I get a few "Gtk-WARNING **: Error loading
> theme icon '' for stock: Icon '' not present in theme" on the console.
Unfortunately, I end up then with same result

By the way, there is still no icons displayed on Ubuntu 7.10 x86_64 (which was the initial issue of this bug).

 ldd libimgicon.so|grep not
        libgnomevfs-2.so.0 => not found
        libgnome-2.so.0 => not found

Ubuntu misses these 32bit libraries so that the component is not loaded.

I just tried a recent hourly for Linux (2007120604) on unstable Debian and I'm also not seeing any moz-icon's without first installing libgnomeui-0.

Created an attachment (id=291998)
Follow up: more soft runtime dependencies

This makes both libgnome and libgnomevfs into soft dependencies, leaving only GTK2 as the hard library dependency and it should allow anyone to get stock icons after this has been checked in.

Created an attachment (id=292000)
...with the configure patch

This includes Walter's configure patch.

Created an attachment (id=292010)
...and the ifdefs

Since we are using types from those libraries, we need to ifdef out the code so that it will compile on machines without those libraries. If my coding is correct, this patch should fix every problem in this bug. Of course I'm frequently wrong so testers, you know what to do :-)

(From update of attachment 292010)
>+ifeq (gtk2,$(MOZ_WIDGET_TOOLKIT))
...
>+ifneq (,$(filter gtk2,$(MOZ_WIDGET_TOOLKIT)))

Why not use the same type of check for both of these?

Created an attachment (id=292013)
...and consistent configure checks

Created an attachment (id=292025)
...and gtk2+ CFLAGS

(In reply to comment #90, comment #92)

> If my coding is correct, this patch should fix every problem in this bug

just tested it on a "libgnomeui-less" gtk2+ linux box (with the small fix above); it does build and run fine: all the icons in the navigation bar, menus, tabs, etc. are back at last... Michael, thanks for your work!

For comment #86, comment #87
Icons are missing on Solaris, too

There's a typo in
http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/decoders/icon/gtk/nsIconChannel.cpp#206

should be
!_gnome_icon_lookup
not
!gnome_icon_lookup

Do we have a bug open for this?

(In reply to comment #93)
> Created an attachment (id=292025) [details]
> ...and gtk2+ CFLAGS
>
Yes, the gtk2+ CFLAGS are needed, then it works. I tested also building with
enable-gnomeui and running on a system lacking libgnome{ui} and gnome-vfs to simulate the Ubuntu situation - and it works, too. Icons are displayed.

Finally, searching for the term "gnomeui" at mxr.mozilla.org I got aware that the build time dependency on libgnomeui up to now seemed to be only necessary to get the icondecoder built. Thus, it appears that after Micheal's patch the libgnomeui dependency could be completely removed from the code (if building the icondecoder with libgnomeui in favor over without libgnomeui doesn't have additional advantages I don't see).

Created an attachment (id=292112)
Complete merged patch

This should be it. This should finally be it. Oh God I hope this is correct.

(In reply to comment #95)
> (In reply to comment #93)
> Finally, searching for the term "gnomeui" at mxr.mozilla.org I got aware that
> the build time dependency on libgnomeui up to now seemed to be only necessary
> to get the icondecoder built. Thus, it appears that after Micheal's patch the
> libgnomeui dependency could be completely removed from the code (if building
> the icondecoder with libgnomeui in favor over without libgnomeui doesn't have
> additional advantages I don't see).

libgnomeui is needed for file type icons, for example the icons in the download manager. We also need it for the object types that are used in the icon code. Its just that after this patch, they're completely optional like in Firefox 2.

(From update of attachment 292112)

I guess this looks fine, one change:

>+#ifdef MOZ_ENABLE_GNOMEUI
> nsresult
> nsIconChannel::InitWithGnome(nsIMozIconURI *aIconURI)
> {
> nsresult rv;
>
>- if (NS_FAILED(ensure_libgnomeui()))
>+ if (NS_FAILED(ensure_libgnomeui()) || NS_FAILED(ensure_libgnome()) || NS_FAILED(ensure_libgnomevfs())) {
>+ gTriedToLoadGnomeLibs = PR_TRUE;
> return NS_ERROR_NOT_AVAILABLE;
>-
>- if (!gnome_program_get()) {
>+ }
>+
>+ gTriedToLoadGnomeLibs = PR_TRUE;

Just set gTriedToLoadGnomeLibs above the if(), don't do it in both the if clause and after it.

(From update of attachment 292112)
I think Vlad's comment is wrong, if you do that, ensure_lib* will skip loading the libraries.

I think the code as written is correct, but confusing. ensure_lib* should not check gTriedToLoadGnomeLibs internally. Instead InitWithGnome should just check it and only call ensure_lib* if it's not set.

Having said that, I think we could land the patch as-is for beta2.

Er yes, roc's right.

(From update of attachment 292112)
Want to land this for b2, as it fixes missing icons on Solaris, 64-bit machines, and people without the proper gtk2/gnome libs.

(From update of attachment 292112)
Sure

Checking in modules/libpr0n/decoders/icon/Makefile.in;
/cvsroot/mozilla/modules/libpr0n/decoders/icon/Makefile.in,v <-- Makefile.in
new revision: 1.26; previous revision: 1.25
done
Checking in modules/libpr0n/decoders/icon/nsIconModule.cpp;
/cvsroot/mozilla/modules/libpr0n/decoders/icon/nsIconModule.cpp,v <-- nsIconModule.cpp
new revision: 1.12; previous revision: 1.11
done
Checking in modules/libpr0n/decoders/icon/gtk/nsIconChannel.cpp;
/cvsroot/mozilla/modules/libpr0n/decoders/icon/gtk/nsIconChannel.cpp,v <-- nsIconChannel.cpp
new revision: 1.16; previous revision: 1.15
done
Checking in modules/libpr0n/decoders/icon/gtk/Makefile.in;
/cvsroot/mozilla/modules/libpr0n/decoders/icon/gtk/Makefile.in,v <-- Makefile.in
new revision: 1.5; previous revision: 1.4
done
Checking in toolkit/library/libxul-config.mk;
/cvsroot/mozilla/toolkit/library/libxul-config.mk,v <-- libxul-config.mk
new revision: 1.55; previous revision: 1.54
done
Checking in modules/libpr0n/decoders/Makefile.in;
/cvsroot/mozilla/modules/libpr0n/decoders/Makefile.in,v <-- Makefile.in
new revision: 1.15; previous revision: 1.14
done
Checking in configure.in;
/cvsroot/mozilla/configure.in,v <-- configure.in
new revision: 1.1895; previous revision: 1.1894
done

If more people can confirm that this works now without libgnomeui, libgnome and libgnomevfs then the relnote is no longer needed.

(From update of attachment 292112)
> PR_STATIC_CALLBACK(void)
> IconDecoderModuleDtor(nsIModule* aSelf)
> {
>-#ifdef MOZ_ENABLE_GNOMEUI
> nsIconChannel::Shutdown();
>-#endif
> }

This removal was wrong, as it caused all non-Linux machines to burn due there only being a nsIconChannel::Shutdown() implementation for Linux and not all platforms. I readded the #ifdef but made it check for MOZ_WIDGET_GTK2 instead of MOZ_ENABLE_GNOMEUI.

(In reply to comment #104)
> If more people can confirm that this works now without libgnomeui, libgnome and
> libgnomevfs then the relnote is no longer needed.

Just tried: it does work fine under those conditions, at least on Linux / GTK2+.

builds fine w/o libgnomeui runs w/o libgnomeui, libgnome and libgnomevfs. Thanks for making it work

The latest Linux hourly is working well with a non-libgnomeui install, just a bunch of gtk warnings in my console to look into (currently using Clearlooks, haven't look at Debian's default Raleigh theme). My default icon set is ugly as sin, but that's more of a Debian thing to work out. Thanks for all your work, b2pre is usable for me again.

The latest nightly looks good for me as well, no warnings on the console.

I'm using 64-bit Ubuntu.
With the nightly build, most of the icons are displayed except gtk-cancel and gtk-stop.

The error:
(firefox-bin:8381): Gtk-WARNING **: Error loading theme icon 'gtk-cancel' for stock: Unable to load image-loading module: /usr/lib32/gtk-2.0/2.10.0/loaders/svg_loader.so: /usr/lib32/gtk-2.0/2.10.0/loaders/svg_loader.so: cannot open shared object file: No such file or directory

Indeed, I don't have a 32-bit version of the svg_loader.

if I understood right this bug is no longer about ubuntu x64 and only about libgnomeui

For missing ubuntu libs see comment #30, you will need 32bit versions of
librsvg2
librsvg2-common
libgsf
libcroco3