Add ids to facilitate add-ons

RESOLVED FIXED

Status

()

Firefox
General
--
enhancement
RESOLVED FIXED
16 years ago
10 years ago

People

(Reporter: Blake Ross, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 obsolete attachments)

(Reporter)

Description

16 years ago
 
(Reporter)

Updated

16 years ago
Target Milestone: --- → Phoenix0.2
(Reporter)

Comment 1

16 years ago
-> hyatt
Assignee: blaker → hyatt
(Reporter)

Updated

16 years ago
Target Milestone: Phoenix0.2 → Phoenix0.3

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: Phoenix0.3 → Phoenix0.4

Comment 2

16 years ago
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.

Updated

16 years ago
Target Milestone: Phoenix0.4 → Phoenix0.5
(Reporter)

Updated

16 years ago
Summary: Add ids to menupopups to facilitate add-ons → Add ids to facilitate add-ons
(Reporter)

Updated

16 years ago
Target Milestone: Phoenix0.5 → Phoenix0.6

Updated

16 years ago
Severity: normal → enhancement

Comment 3

15 years ago
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.

Comment 4

15 years ago
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 → ---

Comment 5

15 years ago
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)

Comment 6

15 years ago
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?)

Comment 7

15 years ago
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

Comment 8

15 years ago
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.

Comment 9

15 years ago
Not so much an ID but related to add-ons anyway.

Would it be possible to include a chunk of generic javascript somewhere that
could be called upon to save preference changes involving extensions? This was
formerly done by the fact that extensions would simply overlay into the existing
preferences dialog. But now each author has to write their own, which seems
somewhat wasteful and also makes converting Mozilla-only extensions a real
chore. In fact I have yet to see an existing Mozilla extension that has been
satisfactorily converted to the new Extensions system - TBE for example calls up
chrome://communicator/content/pref/pref.xul to do it, which works but hardly
seems "clean".

Perhaps a new enhancement bug should be filed on this?

Comment 10

15 years ago
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.

Comment 12

15 years ago
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.

Updated

15 years ago
Blocks: 207518

Updated

15 years ago
No longer blocks: 207518
*** Bug 207518 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

15 years ago
Target Milestone: --- → Firebird1.0

Comment 14

15 years ago
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.

Updated

15 years ago
QA Contact: asa

Comment 15

14 years ago
I'd like ID's for all the menuitems, which would make it alot easier to add
Cutemenu style icons to a skin that I'm distributing.

If not all, then at least the following:

File >
New Window, New Tab, Close Tab, Save Page As, Send Page, Print, Exit

Edit >
Undo, Redo, Cut, Copy, Paste, Delete

View >
Reload, Increase Text Size, Decrease Text Size, Page Source, Full Screen

Go >
Home, History

Bookmarks >
Add to Bookmarks, Manage Bookmarks

Tools >
Downloads, JavaScript Console, Page Info, Options

It may seem like alot, but it would greatly enhance the theme makers
possibilities... (Or so I think anyway.)
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.

Updated

14 years ago
Depends on: 256104

Comment 18

14 years ago
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

Comment 19

14 years ago
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

Comment 20

14 years ago
Actually for branch as well.

[ Persons Cc'ed, since bug 256862 got fixed by actions of those I'm Cc'ing ]

Comment 21

14 years ago
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

Updated

14 years ago
Attachment #157489 - Flags: review?(vladimir)

Comment 23

13 years ago
Created attachment 186057 [details] [diff] [review]
revived patch based on attachment 157488 [details] [diff] [review] for trunk with ids for menuseparators
Attachment #186057 - Flags: review?(mconnor)
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)
Attachment #157489 - Flags: review?(vladimir)
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 #186057 - Attachment is obsolete: true
Attachment #186057 - Flags: review?(mconnor)
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.