ia32-libs missing 32-bit gnome libraries needed for gtk stock icons
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
High
|
|||
ia32-libs (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned | ||
Bug Description
For Firefox 3, we're going to use GTK stock icons for many of the icons used in the browser. Unfortunately, it seems that 64-bit users are missing the needed 32-bit gnome libraries to use the GTK stock icons. See https:/
Comment #25 in the Mozilla bug states the following:
******
here's the issue:
ldd components/
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.
******
It would be great if these missing libraries were added to the ia32-libs Ubuntu package so that users could use the GTK stock icons again. Thanks!
Related branches
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#2 |
Tim, can you hunt down a one-day regression range, by any chance?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#3 |
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#4 |
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#5 |
Checkins in that range:
Looks like this is when we switched to stock icons in bug 396992....
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#6 |
I wonder if there is a problem with 64-bit GTK. 32-bit works fine so I don't think its us...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#7 |
nice to fix, but not a blocker.
Tim, do you have stock icons in other places? (prefwindow, dialogs, etc)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#8 |
I see winstripe icons in Prefs, Toolbar, Addons and other places such as Bookmark manager.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#9 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#10 |
(From update of attachment 287564)
The "OK" button in the about dialog should have a stock icon. Obviously it's not there.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#11 |
Is this a regression? Or were we not using stock icons in Fx2?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#12 |
We weren't using them for FTP listings. Or do you mean in general?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#13 |
I mean in general, as in the OK button in the about dialog.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#14 |
There are plans to use stock icons in the main nav toolbar.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#15 |
renominating based on comment 14. At that point, the browser UI will be unusable without stock icons...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#16 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#17 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#18 |
http://
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:
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#19 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#20 |
Plusing and setting to P3. Please adjust if you thing this is wrong
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#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?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#22 |
(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:
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#23 |
(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?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#24 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#25 |
here's the issue:
ldd components/
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#26 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#27 |
Sounds like Ubuntu ships a broken 32-bit gnome environment; this bug should get
filed upstream with them.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#28 |
(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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#29 |
> Does that mean GTK+ stock icon support depends on Gnome libraries?
Yes. On gnome_icon_lookup and gnome_icon_
If you know a way to achieve equivalent functionality without the GNOME dependency, please do tell!
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#30 |
I just filed Ubuntu launchpad #162993 (https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#31 |
(In reply to comment #29)
> > Does that mean GTK+ stock icon support depends on Gnome libraries?
>
> Yes. On gnome_icon_lookup and gnome_icon_
>
> 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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#32 |
> 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://
[2]http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#33 |
(In reply to comment #32)
> [1]http://
http://
> [2]http://
http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Reed Loden (reed) wrote : | #34 |
For Firefox 3, we're going to use GTK stock icons for many of the icons used in the browser. Unfortunately, it seems that 64-bit users are missing the needed 32-bit gnome libraries to use the GTK stock icons. See https:/
Comment #25 in the Mozilla bug states the following:
******
here's the issue:
ldd components/
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.
******
It would be great if these missing libraries were added to the ia32-libs Ubuntu package so that users could use the GTK stock icons again. Thanks!
Changed in firefox: | |
status: | Unknown → Confirmed |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#35 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#36 |
*** Bug 405619 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#37 |
*** Bug 406037 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#38 |
(In reply to comment #23)
> What about Firefox 2?
>
Firefox 2 uses also some few stock icons on buttons in the pref panel (toolkit/
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#39 |
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/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#40 |
(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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#41 |
(From update of attachment 291129)
You probably also need to add some ifdefs around the moz-icon:// stuff in toolkit/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#42 |
We have to have a solution so that the same release build will display stock icons when libgnomeui is present and will display some other icons when libgnomeui is not present (e.g. for KDE users). So a build-time only solution is a short-term hack but I think the real solution really does block Firefox 3 so we'd better work on that now anyway.
I think we have to ship the winstripe icons as part of gnomestripe and find some way of making the stock icon CSS rules conditional on libgnomeui being present. One way that I think would actually be quite nice is to create a new nsILookAndFeel value to signal whether stock icons are available and use the :-moz-system-metric CSS pseudo-class in theme stylesheets to select the icon. In gtk2/nsLookAndF
http://
by querying the new nsILookAndFeel value.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#43 |
I guess that's simpler than implementing fallback in all the places involved, right?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#44 |
The only problem I see with that approach is that it doesn't tell us *which* icons are available. We should define the nsILookAndFeel value to mean "GTK 2.6 stock icons are available" or something.
This is incredibly lame, GTK+ should provide at least a fallback icon instead of having these APIs just fail when GNOME libraries are missing.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#45 |
bz: 'content' can fall back, but how can you specify fallback content for 'list-style-image'?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#46 |
Created an attachment (id=291153)
Somewhat of a runtime check
This adds a system metric, it does a test-the-waters icon rendering and if nobody's home then it will cause the check to fail and thus not attach the system metric. I haven't made anything to use it yet so this patch by itself won't fix the bug but it brings us very close to CSS-only fallbacks.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#47 |
We could invent some -moz syntax for it, but yeah. It's a bit of a pain.
I kinda wish we weren't abusing that property through all of XUL. :(
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#48 |
To clear a misconception, GTK+ itself does not depend on libgnomeui. libgnomeui is even deprecated by Gnome now, please see comment #33 .
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#49 |
I think there are actually two bugs here.
1) failure to display icons for file types. In our code this depends on libgnomeui. Maybe it doesn't need to. That is what this bug is about.
2) failure to display generic GTK+ stock icons. This is what, say, bug 406037 is about. This does not need to depend on libgnomeui, as far as I can tell, although maybe it does in our code since it's in a file that links directly to libgnomeui.
I think we should reopen bug 406037 and fix issue #2 there, and change the summary on this bug to focus on issue #1.
Either way it seems to me the patches here are not actually needed since they're trying to fix issue #2.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#50 |
Problem 1): there is no need to depend on libgnomeui for this. The icons are pulled from the icon theme... gnome-icon-theme for example, on which Firefox itself does not depend. Using moz-icon, we CAN display not only the icons GTK ships, but also the ones that are only in the fdo icon theme:
moz-icon:
This works, but only displays the icon if it is available in the active theme.
So what could be done here is to test if a list of theme icons are available when FF starts and else fall back on icons that are shipped with firefox, perhaps? If this would be possible, we could use the same for some other icons like window-new and tab-new (which have icons in fdo themes but not GTK, so currently we only use the ones shipping with FF)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#51 |
One other option is that the moz-icon impl could do the fallback itself. That is, define skin URIs that particular stock icons would fall back on, and the newChannel call or whatever could just create a channel for that URI if there is no such stock icon.
That won't help with the file type icons, of course, which are what this bug is about initially...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#52 |
I think comment #49 is really addressing issue #2, right?
bz: I thought of that, but it doesn't really extend across apps unless we create new infrastructure for apps to install their own fallback mappings. How about this alternative: allow moz-icon URLs of the form
moz-icon:
or
moz-icon:
where the fallback is encoded in the rest of the URL somehow.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#53 |
That sounds pretty good to me. I think I like it more than introducing extra selectors, etc...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#54 |
Robert, I was talking about issue #1... but I don't really understand how gnomeui is used, so perhaps what I say does not make any sense. I think GTK has access to the fdo theme somehow, as pure GTK apps (not using gnomeui) can also make use of themed icons to override the GTK stock ones.
Anyway, the new moz-icon scheme you proposed sounds great and it would allow the use of fdo-icon-spec-only icons in the toolbar, too.
Changed in firefox: | |
status: | Confirmed → In Progress |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#55 |
Hm, I'm not sure about the idea of an extra parameter. Its a good idea but it leaves us at the mercy of the image decoder since there is no way in CSS for us to tell which image is being returned.
Because of this, we cannot make new rule declarations to do things like -moz-image-region. Whereas the previous idea with system metrics would allow us to do that and thus not force us to create separate images for every single fallback icon.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#56 |
Created an attachment (id=291313)
Soft dependency on libgnomeui
This will remove the hard dependency that the icon decoder has on libgnomeui, by changing the libgnomeui function calls to soft library symbol lookups. Since the dependency is now soft this should mean that you no longer need libgnomeui to get the stock icons, which actually use a GTK function.
Libgnomeui was necessary for filetype icons so no libgnomeui means no download manager icons, but this was always the behaviour when libgnomeui was not found.
I'll want a review quickly since B2 freeze is too close... :-(
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#57 |
(From update of attachment 291313)
Are you not going to do PR_UnloadLibrary somewhere so you don't leak the original load?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#58 |
Created an attachment (id=291327)
...this time without the leaks!
Right, I probably should do that.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#59 |
Created an attachment (id=291374)
Global scope
Uses global scope to prevent the overhead of constantly loading and unloading libraries.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#60 |
> gLibGnomeUi
gLibGnomeUI
move all the FindFunctionSymbol calls under "if (!gTriedToLoadL
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#61 |
Created an attachment (id=291377)
Global scope 2
Fix review comments. gnome_init was a #define in a header, not a symbol, hence the change.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#62 |
Created an attachment (id=291484)
Global scope 3
Good news roc, there's a shutdown function so we aren't forced to leak the library after all.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#63 |
Move the "if (!gTriedToLoadL
+ if (gLibGnomeUI) {
+ PR_UnloadLibrar
+ gLibGnomeUI = nsnull;
+ }
Also set gTriedToLoadLib
Otherwise looks just right!
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#64 |
Created an attachment (id=291504)
Patch 4
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#65 |
Created an attachment (id=291508)
Patch 4.01
Er, this is the right patch.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#66 |
So, will this patch completely fix this bug, or is there more work to do after this patch lands?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#67 |
(In reply to comment #65)
> So, will this patch completely fix this bug, or is there more work to do after
> this patch lands?
This patch should completely fix the bug, but since I don't have a machine that doesn't have libgnomeui I can't really tell.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#68 |
If you're going to close this bug, a new one should be filed for this:
(In reply to comment #53)
> Anyway, the new moz-icon scheme you proposed sounds great and it would allow
> the use of fdo-icon-spec-only icons in the toolbar, too.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#69 |
Checking in modules/
/cvsroot/
new revision: 1.25; previous revision: 1.24
done
Checking in modules/
/cvsroot/
new revision: 1.14; previous revision: 1.13
done
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#70 |
None of the moz-icon fallback schemes we've worked out so far seem all that appealing, so I'm not that excited about using fdo-icon-spec-only icons. Someone can file a bug for it I guess.
This patch does not fix my issue #1: icons for file types not appearing when lignomeui is unavailable. Someone should definitely file a bug on that. It's not very high priority though.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#71 |
I'll file the follow-up bug. Having no mime icons in 3 places (ftp listings, applications list, download manager) doesn't seem to be the way to go.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#72 |
Filed as Bug 406868.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#73 |
Created an attachment (id=291614)
post-commit minefield screenshot
(In reply to comment #66)
> This patch should completely fix the bug, but since I don't have
> a machine that doesn't have libgnomeui I can't really tell.
Enclosed screenshot was taken on a linux x86_64 / gtk2+ build including the newly commited fix, on a system without libgnomeui installed: unfortunately, it doesn't seem to work yet. Can anyone confirm or infirm this?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#74 |
(In reply to comment #72)
> Enclosed screenshot was taken on a linux x86_64 / gtk2+ build including the
> newly commited fix, on a system without libgnomeui installed: unfortunately, it
> doesn't seem to work yet. Can anyone confirm or infirm this?
>
Did you build this yourself? Currently you still need libgnomeui-dev for the icon code to be linked at compile-time. Try a build from the official server which has libgnomeui headers.
/me makes a note to fix this for self-builders
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#75 |
Drivers, this is what I want you to relnote:
If you wish to build Firefox from source then the libgnomeui headers must be installed and the configure option --enable-gnomeui must be set, otherwise icons may not appear in the navigation toolbar and other places where native GTK icons are used.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#76 |
(In reply to comment #73)
> Did you build this yourself?
Yes.
> Currently you still need libgnomeui-dev for the icon code to be linked
> at compile-time.
I can see that now... I should have looked at your code: thanks for the
explanation.
> Try a build from the official server which has libgnomeui headers.
Just installed libgnomeui with headers, rebuilt mozilla, removed
libgnomeui, and it does work.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#77 |
IMHO This fix is not good enough they are distributions which don't distribute libgnomeui and this is a regression from Firefox2. Toolbar icons should be shown even if libgnomeui headers not found.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#78 |
s/they/there
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#79 |
(In reply to comment #76)
> IMHO This fix is not good enough they are distributions which don't distribute
> libgnomeui and this is a regression from Firefox2. Toolbar icons should be
> shown even if libgnomeui headers not found.
-> bug 406868
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#80 |
Actually, we could have this code build when MOZ_ENABLE_GNOMEUI is not set, and use #ifdef around the libgnomeui headers, and #ifdef out the file type icon code. Then you'd still get icons in the Firefox UI even if libgnomeui is not available at build time.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#81 |
(In reply to comment #79)
> Actually, we could have this code build when MOZ_ENABLE_GNOMEUI is not set, and
> use #ifdef around the libgnomeui headers, and #ifdef out the file type icon
> code. Then you'd still get icons in the Firefox UI even if libgnomeui is not
> available at build time.
That would be very nice indeed.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#82 |
Yeah. I don't want to have libgnomeui installed, but having icons will be very good :)
Changed in firefox: | |
status: | In Progress → Fix Released |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#83 |
Created an attachment (id=291702)
Patch using ifdefs
I don't know if this compiles w/o libgnomeui, but knowing the recent quality of my code lately I doubt it :P
This needs testers before I ask for review, but it will need to happen quickly because the floodgates are starting to open for Beta 2.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#84 |
(From update of attachment 291702)
Can you file a new bug for this? Also, http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#85 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#86 |
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#87 |
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
Ubuntu misses these 32bit libraries so that the component is not loaded.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#88 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#89 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#90 |
Created an attachment (id=292000)
...with the configure patch
This includes Walter's configure patch.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#91 |
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 :-)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#92 |
(From update of attachment 292010)
>+ifeq (gtk2,$
...
>+ifneq (,$(filter gtk2,$(
Why not use the same type of check for both of these?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#93 |
Created an attachment (id=292013)
...and consistent configure checks
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#94 |
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!
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#95 |
For comment #86, comment #87
Icons are missing on Solaris, too
There's a typo in
http://
should be
!_gnome_icon_lookup
not
!gnome_icon_lookup
Do we have a bug open for this?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#96 |
(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).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#97 |
Created an attachment (id=292112)
Complete merged patch
This should be it. This should finally be it. Oh God I hope this is correct.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#98 |
(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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#99 |
(From update of attachment 292112)
I guess this looks fine, one change:
>+#ifdef MOZ_ENABLE_GNOMEUI
> nsresult
> nsIconChannel:
> {
> nsresult rv;
>
>- if (NS_FAILED(
>+ if (NS_FAILED(
>+ gTriedToLoadGno
> return NS_ERROR_
>-
>- if (!gnome_
>+ }
>+
>+ gTriedToLoadGno
Just set gTriedToLoadGno
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#100 |
(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 gTriedToLoadGno
Having said that, I think we could land the patch as-is for beta2.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#101 |
Er yes, roc's right.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#102 |
(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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#103 |
(From update of attachment 292112)
Sure
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#104 |
Checking in modules/
/cvsroot/
new revision: 1.26; previous revision: 1.25
done
Checking in modules/
/cvsroot/
new revision: 1.12; previous revision: 1.11
done
Checking in modules/
/cvsroot/
new revision: 1.16; previous revision: 1.15
done
Checking in modules/
/cvsroot/
new revision: 1.5; previous revision: 1.4
done
Checking in toolkit/
/cvsroot/
new revision: 1.55; previous revision: 1.54
done
Checking in modules/
/cvsroot/
new revision: 1.15; previous revision: 1.14
done
Checking in configure.in;
/cvsroot/
new revision: 1.1895; previous revision: 1.1894
done
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#105 |
If more people can confirm that this works now without libgnomeui, libgnome and libgnomevfs then the relnote is no longer needed.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#106 |
(From update of attachment 292112)
> PR_STATIC_
> IconDecoderModu
> {
>-#ifdef MOZ_ENABLE_GNOMEUI
> nsIconChannel:
>-#endif
> }
This removal was wrong, as it caused all non-Linux machines to burn due there only being a nsIconChannel:
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#107 |
(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+.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#108 |
builds fine w/o libgnomeui runs w/o libgnomeui, libgnome and libgnomevfs. Thanks for making it work
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#109 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#110 |
The latest nightly looks good for me as well, no warnings on the console.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Matthias Klose (doko) wrote : | #111 |
confirmed; I don't think we should add the complete gnome libs to ia32-libs.
Changed in ia32-libs: | |
importance: | Undecided → Wishlist |
status: | New → Confirmed |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Timothy Babych (tymofiy) wrote : | #112 |
In some places (alerts, questions) Firefox3 uses svg icons, so following libraries are needed too:
librsvg2
librsvg2-common
libgsf
libcroco3
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#113 |
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/
Indeed, I don't have a 32-bit version of the svg_loader.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#114 |
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
John Pham (jhnphm) wrote : | #115 |
The lack of SVG seems to affect Firefox 3's stop button when the Human theme is used:
(firefox-
(firefox-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Arthur (moz-liebesgedichte) wrote : | #116 |
Also makes gtk-cancel and gtk-dialog-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Arthur (moz-liebesgedichte) wrote : | #117 |
This affects adobe's acrobat reader (8.1.2, tar.bz2 package) as well.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Arthur (moz-liebesgedichte) wrote : | #118 |
Also affects e-Lohnausweis 3.4 (27.12.2007), a salary tax form management software of the Swiss government (partly Java based) with Linux version.
(SWT:26586): Gtk-WARNING **: Error loading theme icon 'gtk-dialog-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Luka Renko (lure) wrote : | #119 |
Similar issue (even worse result) with RawTherapee 2.3 on Hardy/amd64:
(rt:20836): Gtk-WARNING **: /usr/lib/
/usr/share/
/usr/share/
/usr/share/
/usr/share/
(rt:20836): Gtk-WARNING **: /usr/lib/
processing file /usr/share/
processing file /usr/share/
processing file /usr/share/
terminate called after throwing an instance of 'Gdk::PixbufError'
Aborted (core dumped)
More info is available on RawTherapee forums:
http://
According to some users there, Debian and Ubuntu Gutsy is working fine with RawTherapee 2.3 and amd64
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Sylvain Pasche (sylvain-pasche) wrote : | #120 |
There is another issue on Hardy which will make no stock icon visible. See https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Sylvain Pasche (sylvain-pasche) wrote : | #121 |
Matthias,
This is not a duplicate of bug 162993. The trouble here is that some libraries are not included in ia32-libs, which makes the above Firefox component not to load. Right now on Hardy no stock icons are visible at all because of bug 162993, but when it is fixed there will still be some stock icons not visible because of the lack of these libraries.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Matthias Klose (doko) wrote : | #122 |
ok, then closing. According to https:/
mozilla can do without the gnome libs. If not, please reopen and reassign to firefox
Changed in ia32-libs: | |
status: | Confirmed → Fix Released |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Arthur (moz-liebesgedichte) wrote : | #123 |
Verified fixed in hardy with Minefield (Firefox 3 nightly), Seamonkey (stable) and Acrobat Reader. *Big smile*. Verifying the fix was blocked by bug 190227 which is now fixed as well.
Changed in firefox: | |
importance: | Unknown → High |
Created an attachment (id=287564)
nightly screeshot