Bug for PRD items ADD-002a and ADD-002b

beltzner and Madhava, need some advice on how you'd like to access the options of extensions within the prefpanels. In the screenshot selecting the extension from the dropdown will open its options. Since extension names can be quite long I've limited the width of the drop down and cropped the extension name. I'd also like to add a "Manage Add-ons..." button on this tab. Thoughts?

notes 1. to keep the state in sync with the add-ons mgr. we need to use an RDF template. Bug 285076 makes this difficult and even with workarounds it is impossible to display a list though we can display a menulist and use AddDataSource in an onpopupshowing handler and RemoveDataSource in an onpopuphiding handler to avoid the nastiness such as the datasource not being torn down properly which is probably also Bug 285076. Another option that regretfully wouldn't keep the two in sync would be to create the list of extensions with options without using an RDF template when the prefpane is loaded. 2. there are no accesskeys available that are appropriate in the advanced pane. After bug 393003 is fixed only "j", "q", "z" will be available. Bug 143065 is the fix for this and getting that fixed for 3.0 is highly unlikely. I believe that a hackish workaround could be written for the advanced tab by removing accesskeys for tabs that are not selected and adding them for the selected tab. No, I'm not volunteering. :P Another option would be to add this to another prefpane but there isn't much real estate anywhere else and this doesn't IMO warrant its own prefpane.

Instead of a menulist, which is hard to use, you could provide a richlistbox with the extensions, and an Options button on the selected extension. Oh wait, I've seen that somewhere already... How about this: If you want to manage add-ons, open the f***ing add-ons manager? Seriously, please stop adding needless stuff to the options window - bug 384125 makes me still choke. This is not the Mozilla Suite. Please remove this from the PRD and WONTFIX this bug.

The rationale for adding the ability to manage extension prefs has to do with some subset of users going into the app preferences expecting to find extension preferences there which I believe is a valid concern. The initial design as requested by the User Experience people was to have an extension's prefs displayed within preferences itself but that would require severe restrictions on how extensions provide preferences. The addition of this to preferences was discussed during the PRD planning phase and no one besides myself was against adding it... so, I of course was assigned to add this. :P btw: though I know your comment regarding using a richlistbox was meant sarcastically it is important to note that we wouldn't be able to use the richlistbox with an RDF datasource inside a prefpane due to Bug 285076... why is it important? Because I wouldn't be surprised if a request was made to add one and doing so would be a major PITA.

I agree that a number of users will go to the Prefs panel looking for ways to change an add-on's preferences, and may get confused and frustrated if there's nothing there. This discoverability problem is a real one. It seems odd though, to have two completely mirrored places in the UI to make these changes. Theoretically, one way to get around this would be to have all of the Add-ons Manager in the Prefs/Options panel, but, given how user-facing we want to make the Add-ons Manager in general (i.e. the Add-ons Manager redesign), I don't think it belongs there. Really, nothing that we want to encourage the user to interact with belongs in Preferences/Options. How about, rather than a full-on prefs panel with add-on picker, we provide a button titled something like "Configure Add-on Preferences..." that brings up the Add-ons Manager? Users who look in Preferences have a sign-post that leads them to where the prefs really are, and get introduced to the Add-ons Manager in the process, and we don't have to replicate functionality (which, aside from being a pain for us, is also going to be odd for users). As to where in the prefs panel to put this, sticking it in "Advanced" seems like the wrong course of action -- the advanced section really ought to be where we bury those options that we expect hardly anyone to go looking for but that we have to surface for some reason. Really nitpicky things, like turning off auto-spellchecking or being all "custom" about what updates to check for (both are in there). The whole argument behind putting Add-ons prefs in here somewhere, though, is that we expect that people will be looking for them. If these prefs belong anywhere in the main Preferences/Options dialog, they belong somewhere more prominent. Maybe on "Main"?

I'm fine with just providing a button to open the add-ons manager and actually recommended we do exactly that but got pushback to have them available directly from preferences/options. I agree that Main would be the place to put it but there currently isn't room for it and I am loathe to just increase the height of the pref window... suggestions?

A button to open the Add-ons manager is much better indeed. The Add-ons manager is the central place to install new add-ons, restart Firefox, configure add-ons, and uninstall them again. Main is indeed stuffed already. I'd go for a new tab on Advanced and a label telling users that they can access extension options in the Add-ons manager.

Comment on attachment 278491 [details] screenshot I implemented this per the email you sent me. Thanks!

Since you're already this section of code ... shouldn't "Startup" be "Start-up" for the same reason that "Add-ons" is hyphenated? http://www.webster.com/cgi-bin/dictionary?sourceid=Mozilla-search&va=startup

(In reply to comment #12) I leave the terminology to the UI / UX team which approved the use of startup. Not going to do that in this bug.

- <description control="warningSettings" flex="1">&chooseWarnings.label;</description> + <label control="warningSettings" flex="1">&chooseWarnings.label;</label> hrm?

(In reply to comment #14) > - <description control="warningSettings" > flex="1">&chooseWarnings.label;</description> > + <label control="warningSettings" > flex="1">&chooseWarnings.label;</label> > > hrm? See attachment #278493 [details] as to why I changed this. I can just file a followup bug on this if you prefer though I doubt I'll have time to take it.

Filed Bug 393945 for the security prefpane's last groupbox being partially cutoff

Comment on attachment 278507 [details] [diff] [review] patch w/o security pref pane fix r=mano.

One last string change. The button text makes sense given that what it launches the Add-ons Manager, but in the left-justified string where we can offer an explanation suited to the current context, I think I'd use a more specific word than "Manage." If they're opening the Options/Preferences panel to do something, it's most like because they're trying to change options/preferences, rather than general "management." Also, rather than introducing the new term "settings" where we otherwise talk about "Options" on Windows and "Preferences" on Mac, I think I'd rather use the same terminology. How about something like this? [mac] "Change preferences for your add-ons." [win] "Change options for your add-ons"

Comment on attachment 278491 [details] screenshot with the string changes in comment 19

mano, had to change the xul due to the strings asked for by Madhava... could you please review this again?

Comment on attachment 278834 [details] [diff] [review] patch - updated to comments r=mano.

Checked in to trunk Checking in mozilla/browser/components/preferences/main.xul; /cvsroot/mozilla/browser/components/preferences/main.xul,v <-- main.xul new revision: 1.14; previous revision: 1.13 done Checking in mozilla/browser/components/preferences/main.js; /cvsroot/mozilla/browser/components/preferences/main.js,v <-- main.js new revision: 1.13; previous revision: 1.12 done Checking in mozilla/browser/locales/en-US/chrome/browser/preferences/main.dtd; /cvsroot/mozilla/browser/locales/en-US/chrome/browser/preferences/main.dtd,v <-- main.dtd new revision: 1.7; previous revision: 1.6 done

Filed bug 394299 on the UI being cut off at the bottom of the options pane.

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; es-ES; rv:1.9b2pre) Gecko/2007112804 Minefield/3.0b2pre