Assignee: blaker → hyatt
Not sure of the reaction to this comment, but what the heck: concerning the ids that are added - could it be possible to try to make sure that all the id's are unique across the app? As if there was an appwide namespace. The reason I even mention this is that it might make someone who is developing for phoenix to be able to uniquely locate any id across all the xul pages - perhaps for some automation or tool of some kind. This comment may be completely spurious, but since phoenix is something new, I thought it might be worth mentioning. If anything - once the id's are added - someone could index them so that when an extension developer wanted to know "how do I overlay over menu x" they'll be able to search via lxr or however and be able to know just from the id it it's the right location.
Summary: Add ids to menupopups to facilitate add-ons → Add ids to facilitate add-ons
The new "options" dialog xul is fairly lacking in ids right now. It will be essential (IMO) to add appropriate ids to this area so that some themes can be updated to work with Feb.+ builds as well as new themes, unless extending the dialog is to be discouraged in favor of individual extension prefs.
cd_cook wrote: > unless extending the > dialog is to be discouraged in favor of individual extension prefs. individual extension prefs is the way to go. -> reassigning it to me please request missing ID here.
Assignee: hyatt → chanial
Status: ASSIGNED → NEW
Target Milestone: Phoenix0.6 → ---
likely to be WONTFIXed : ) ids for menus : file, edit, view, go, 'tasks' and help [bookmarks already has an id] + OT add ' persist="hidden"' on all menubar menus + OT to help Chris Cook with bug 193486, separate the menu section from browser.xul, as navigator, which has globalOverlay and navigatorOverlau (maybe others too)
This probably applies to both mozilla and phoenix but could we get an ID for the window of the download progress dialog nsProgressDialog.xul In phoenix found at: \phoenix\chrome\toolkit\content\global <window xmlns:html="http://www.w3.org/1999/xhtml" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" class="dialog" title="&defaultTitle;" onload="notifyObserver('onload')" onunload="notifyObserver('onunload')"> (or can this be referenced by class, and if so, is that better?)
I'd like to request a few IDs be added to make the Mac OS X menubar code work (/widget/src/mac/nsMenuBarX.cpp) In browser.xul, add: - id="menu_FileQuitSeparator" to <menuseparator/> just above the Quit menuitem - id="menu_preferences" to Prefs menuitem - id="aboutName" to About menuitem
How about ID tags for each grouping in Options. For example, Privacy has Disk Cache, but not Memory Cache settings. If an extension wanted to add in Mem Cache, it needs an ID to hook in.
I'll second comment 5, regarding id tags for the individual menus. The only way currently to reference a menu is by the label tag (eg menu[label="File"] in CSS,) which is not consistent across different locales.
I'd like ids on the "Frame" menupopup, and on the menuitems it contains. in browser.xul: <menu id="frame" label="&thisFrameMenu.label;" accesskey="&thisFrameMenu.accesskey;"> <menupopup> <--- here and its children Right now it doesn't look like it's possible to overlay the Frame menu.
I'd like to see as many items as possible given ids. I have an extension that allows you to pick and choose what menu items you want to see. I will have to go in and assign an id to each item in the code if these aren't added. If they are added then I could do it in an overlay.
*** Bug 207518 has been marked as a duplicate of this bug. ***
I am requesting an id ("key_textZoomReset") for the following keyset key in browser/content/browser.xul: <key key="&textZoomResetCmd.commandkey;" oncommand="ZoomManager.prototype.getInstance().reset();" modifiers="accel"/> I override this key in my TextZoom extension, which will be around forever if the devs continue to support the belief that text-zooming should not be a permanently configurable preference.
i would like to see some ids added in bookmarksPoperties.xul so that i can add some favicon options in the "Info" tab... preferably for the <rows> tag that contains the <row>'s for name, location, shortcutUrl, and description...
I'd like to add a menuitem to "Bookmarks" Menu (id="bookmarks-menu"). Please give ids to its child menupopup element and menuseparator. menupopup http://lxr.mozilla.org/firebird/source/browser/base/content/browser-menubar.inc#271 menuseparator http://lxr.mozilla.org/firebird/source/browser/base/content/browser-menubar.inc#280 Thanks.
Created attachment 156526 [details] [diff] [review] Patch for trunk : Add ids for menus, menupopups, menuseparators Partially addressing comment 5, comment 7, comment 10 and comment 17 Also adds bookmark URI mouseover
Created attachment 157486 [details] [diff] [review] Patch for trunk against r 1.35 of browser/base/content/browser-menubar.inc checkin for bug 256862 (for trunk at present) fixed part 1 of comment 17
Attachment #156526 - Attachment is obsolete: true
Actually for branch as well. [ Persons Cc'ed, since bug 256862 got fixed by actions of those I'm Cc'ing ]
Created attachment 157488 [details] [diff] [review] Patch for trunk against r 1.35 of browser/base/content/browser-menubar.inc w/o mouseover changes on bookmarks menu
Created attachment 157489 [details] [diff] [review] equivalent of attachment 157488 [details] [diff] [review] for branch
Created attachment 186057 [details] [diff] [review] revived patch based on attachment 157488 [details] [diff] [review] for trunk with ids for menuseparators
Comment on attachment 157489 [details] [diff] [review] equivalent of attachment 157488 [details] [diff] [review] for branch (clearing review request.. this didn't make it into 1.0, but should make it into 1.1)
Assignee: p_ch → nobody
QA Contact: general
Comment on attachment 186057 [details] [diff] [review] revived patch based on attachment 157488 [details] [diff] [review] for trunk with ids for menuseparators At least part of this patch is rotten, IDs were added as part of bug 167391.
Attachment #157488 - Attachment is obsolete: true
Attachment #157486 - Attachment is obsolete: true
Attachment #157489 - Attachment is obsolete: true
Hardware: PC → All
Target Milestone: Firefox1.0 → ---
We've fixed a bunch of stuff, please file bugs for places that still need IDs.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.