Closed Bug 14922 Opened 21 years ago Closed 20 years ago
[FEATURE] must be able to install preference panes
Since we can install add-on components with add-on preferences and add-on chrome, we must be able to install a preference pane for them. Not sure who owns the preference pane UI. The install may need to do something special, but hopefully it's just a matter of installing extra files in a special place as is the case with the default preference files and will be the case with chrome-registry fragments once that feature is implemented. Could this be handled through XUL overlays?
this is a technical questions and should be owned by the apprunner team. From a UI perspective it's fine that new components can add new panes, as long is the current structure does not break. New panes should be appended at the end of prefs.
matt, you seem to know about this.
Summary: [feature] must be able to install preference panes → [FEATURE] must be able to install preference panes
Target Milestone: M13 → M15
Move to M15 until we figure out what this really means ...
spam: in my testing realm, so reassigning qa contact to me, en masse.
Bulk move of all Pref UI component bugs to new Preferences component. Pref UI component will be deleted.
Component: Pref UI → Preferences
Move to M16 for now ...
Target Milestone: M15 → M16
Moving back to M16 -- no explanation given for move to "future". CC'ing Ben because last I heard he was working on the pref dialog. This feature is required if we are ever going to ship "optional" or 3rd party components that have preference panes. Netscape actually ships one such major component: Instant Messenger. But something like Chatzilla or XMLTerm would also be examples.
Target Milestone: Future → M16
*** Sigh. *** Ben, is this actually implementable for Netscape 6?
Assignee: matt → ben
Status: ASSIGNED → NEW
Target Milestone: M16 → M17
Putting on [nsbeta2-] radar. Please renominate if required for IM prefs.
dan, this was possible using dynamic overlays, and now those have gone the way of the dodo I'm told that this can be done using the manifest files in packages. talk to hyatt.
Move to M20 target milestone.
Target Milestone: M17 → M20
I don't understand the move to M20. Either this feature works and it should be closed, or it doesn't and it's either nsbeta2+ or cut. If cut it should be M30 or Future, because M20 is likely to hit before rtm. If it works and AIM, for example, simply doesn't do it right *that* could be fixed later, but that should be a different more specific bug
OK, my understanding is that this "works"... I've converted mail to add itself to the pref tree only when it is installed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.