Closed
Bug 504275
Opened 16 years ago
Closed 16 years ago
Bookmark favicon images with menus_have_icons=false
Categories
(Firefox :: Menus, defect)
Tracking
()
RESOLVED
FIXED
Firefox 3.6a1
Tracking | Status | |
---|---|---|
status1.9.1 | --- | .2-fixed |
People
(Reporter: micmon, Assigned: ventnor.bugzilla)
References
Details
(Keywords: verified1.9.1)
Attachments
(3 files, 1 obsolete file)
505 bytes,
patch
|
dao
:
review+
beltzner
:
approval1.9.1.2+
|
Details | Diff | Splinter Review |
104.89 KB,
image/png
|
Details | |
125.50 KB,
image/png
|
Details |
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•16 years ago
|
||
So what's the problem? You're saying that bookmark menu items should always have an icon?
Assignee | ||
Comment 2•16 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•16 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•16 years ago
|
||
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 5•16 years ago
|
||
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•16 years ago
|
||
Sure.
Attachment #388841 -
Attachment is obsolete: true
Attachment #388881 -
Flags: review?(dao)
Attachment #388841 -
Flags: review?(dao)
Reporter | ||
Comment 7•16 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•16 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•16 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•16 years ago
|
Attachment #388881 -
Flags: review?(dao) → review+
Assignee | ||
Updated•16 years ago
|
Keywords: checkin-needed
Comment 10•16 years ago
|
||
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Updated•16 years ago
|
Attachment #388881 -
Flags: approval1.9.1.2?
Comment 11•16 years ago
|
||
Comment on attachment 388881 [details] [diff] [review]
Patch
a1912=beltzner
Attachment #388881 -
Flags: approval1.9.1.2? → approval1.9.1.2+
Updated•16 years ago
|
Keywords: checkin-needed
Comment 12•16 years ago
|
||
status1.9.1:
--- → .2-fixed
Keywords: checkin-needed
Comment 13•16 years ago
|
||
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•16 years ago
|
||
Sure, set /desktop/gnome/interface/menus_have_icon to false in gconf or untick the checkbox in Preferences->Appearance->Interface
Comment 15•16 years ago
|
||
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•16 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?
Comment 17•16 years ago
|
||
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).
Comment 18•16 years ago
|
||
You probably need to restart Firefox (which is suboptimal and might be a bug on its own).
Comment 19•16 years ago
|
||
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?
Comment 20•16 years ago
|
||
Yes.
Comment 22•16 years ago
|
||
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?
Comment 23•16 years ago
|
||
(In reply to comment #22)
> Should that be filed as a separate bug?
Yes.
Comment 24•16 years ago
|
||
Filed those as Bug 508221 and Bug 508223
See Also: → https://launchpad.net/bugs/408361
You need to log in
before you can comment on or make changes to this bug.
Description
•