Looking for saved searches? click on "Search Bugs" above.

Bookmark favicon images with menus_have_icons=false

RESOLVED FIXED in Firefox 3.6a1

Status

()

Firefox
Menus
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: micmon, Assigned: Michael Ventnor)

Tracking

({verified1.9.1})

3.5 Branch
Firefox 3.6a1
x86
Linux
verified1.9.1
Points:
---

Firefox Tracking Flags

(status1.9.1 .2-fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

9 years ago
GNOME has decided¹ to set menus_have_icons to false as a default for the coming 2.28 release. What this means is that menus will no longer show icons.

This however also affects bookmark menus in Firefox. So, menu items which are bookmarks with favicon (and only those) should set the "always-show-icons" property (GtkImageMenuItem).

Can this change be done in the 3.5 branch? As far as I know, setting the property does not have a negative effect for users of menus_have_icons=true

[1] http://bugzilla.gnome.org/show_bug.cgi?id=557469
(Assignee)

Comment 1

9 years ago
So what's the problem? You're saying that bookmark menu items should always have an icon?
(Assignee)

Comment 2

9 years ago
And if that's the case, should folders/smart folders that are submenus also show icons?

This really seems like an odd inconsistency from the GNOME folks, almost like a begrudging admission that icons do actually work ;-)
(Reporter)

Comment 3

9 years ago
Well, not talking about my own preferences or feelings regarding this change here... :)

But the GNOME HIG explictly mentions¹ this case: "Show icons for bookmark entries on the Bookmarks menu that indicate the type of the bookmark, even if the user has globally turned off icons for other menu items on the desktop."

As I read this, smart bookmarks should indicate that they are smart bookmarks. I don't think "smart" folders are covered by this.

[1] http://www.gnome.org/~calum/hig-devel/menus-standard.html#menu-standard-bookmarks
(Assignee)

Comment 4

9 years ago
Created attachment 388841 [details] [diff] [review]
Patch

This has buckley's chance of making 3.5 (though you can try and request it, I guess), and if the schedule plans did change as proposed in the last meeting, then we only have 1 week for it to be certain of making 3.6.
Assignee: nobody → ventnor.bugzilla
Attachment #388841 - Flags: review?(dao)
Comment on attachment 388841 [details] [diff] [review]
Patch

Can you put this in browser/base/content/browser.css with %ifdef MOZ_WIDGET_GTK2? That would be consistent with xul.css.
(Assignee)

Comment 6

9 years ago
Created attachment 388881 [details] [diff] [review]
Patch

Sure.
Attachment #388841 - Attachment is obsolete: true
Attachment #388881 - Flags: review?(dao)
Attachment #388841 - Flags: review?(dao)
(Reporter)

Comment 7

9 years ago
(In reply to comment #4)
> This has buckley's chance of making 3.5 (though you can try and request it, I
> guess), and if the schedule plans did change as proposed in the last meeting,
> then we only have 1 week for it to be certain of making 3.6.

When is 3.6 due out then? GNOME 2.28 is set for a Sep 23 release and Ubuntu will have a release shortly after that.
(Assignee)

Comment 8

9 years ago
Assuming they are planning to quickly stabilize 1.9.2 in order to ship Fennec 1.0 on it (it's not 100% confirmed), the plan is to ship 3.6 "this fall" according to recent meeting notes.
(Reporter)

Comment 9

9 years ago
Ok... "this fall" sounds like Fedora 12 would ship it (or some RC, as they did with 3.5) but Ubuntu will probably not. Probably worth asking distributions to ship the patch with 3.5 (if they ship GNOME 2.28).

Updated

9 years ago
Attachment #388881 - Flags: review?(dao) → review+
(Assignee)

Updated

9 years ago
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/c1840493c832
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1

Updated

9 years ago
Attachment #388881 - Flags: approval1.9.1.2?
Comment on attachment 388881 [details] [diff] [review]
Patch

a1912=beltzner
Attachment #388881 - Flags: approval1.9.1.2? → approval1.9.1.2+

Updated

9 years ago
Keywords: checkin-needed
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0592119e3de1
status1.9.1: --- → .2-fixed
Keywords: checkin-needed
Is there a way QA can verify this on Firefox 3.5.2 without GNOME 2.28? Do we have to wait until Ubuntu/Fedora become updated?
(Reporter)

Comment 14

9 years ago
Sure, set /desktop/gnome/interface/menus_have_icon to false in gconf or untick the checkbox in Preferences->Appearance->Interface
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Our menus look the same whether OS Preferences->Appearance->Interface->"Show icons in menus" is enabled or disabled.

Is this expected behaviour?
(Reporter)

Comment 16

9 years ago
Surely not... I think it works for me, though. Using Fx 3.5.1 and the code from the patch in userChrome.css... have you tested if menu icons disappear from other GTK apps?
I can see the icons disappear from other menus (Applications, Places, System).  In Firefox 3.5.2 they look the same (no matter the pref setting).
You probably need to restart Firefox (which is suboptimal and might be a bug on its own).
Created attachment 391988 [details]
Screenshot

Here is a screenshot of what I am seeing.  Notice the icon for Organize Bookmarks is removed when the pref is disabled.  All other icons that were there before are present.  Is this expected?
Yes.
Excellent.  Based on that, verified1.9.1.
Keywords: verified1.9.1
Created attachment 392287 [details]
quicksearch and tab dropdown

Seems this also affects the favicons for the quick search box dropdown and tabs dropdown (that both should have icons according to the new guidelines). Should that be filed as a separate bug?
(In reply to comment #22)
> Should that be filed as a separate bug?

Yes.
Filed those as Bug 508221 and Bug 508223

Updated

7 years ago
You need to log in before you can comment on or make changes to this bug.