[FEATURE] must be able to install preference panes

VERIFIED FIXED

Status

P1
normal
VERIFIED FIXED
19 years ago
14 years ago

People

(Reporter: dveditz, Assigned: bugs)

Tracking

Trunk
All
Other

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-])

(Reporter)

Description

19 years ago
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?

Updated

19 years ago
Assignee: shuang → german

Comment 1

19 years ago
German?

Updated

19 years ago
Assignee: german → don

Comment 2

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

Updated

19 years ago
Priority: P3 → P1
Target Milestone: M13

Updated

19 years ago
Assignee: don → matt

Comment 3

19 years ago
matt, you seem to know about this.

Updated

19 years ago
Summary: [feature] must be able to install preference panes → [FEATURE] must be able to install preference panes
Target Milestone: M13 → M15

Comment 4

19 years ago
Move to M15 until we figure out what this really means ...
QA Contact: cpratt → sairuh
spam: in my testing realm, so reassigning qa contact to me, en masse.

Comment 6

19 years ago
Bulk move of all Pref UI component bugs to new Preferences component.  Pref UI 
component will be deleted.
Component: Pref UI → Preferences

Updated

19 years ago
Status: NEW → ASSIGNED
Depends on: 30512

Comment 7

19 years ago
Move to M16 for now ...
Target Milestone: M15 → M16

Updated

19 years ago
Target Milestone: M16 → Future
(Reporter)

Comment 8

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

Comment 9

19 years ago
*** Sigh. ***

Ben, is this actually implementable for Netscape 6?
Assignee: matt → ben
Status: ASSIGNED → NEW
Keywords: nsbeta2
Target Milestone: M16 → M17

Comment 10

19 years ago
Putting on [nsbeta2-] radar. Please renominate if required for IM prefs.
Whiteboard: [nsbeta2-]
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. 

Comment 12

19 years ago
Move to M20 target milestone.
Target Milestone: M17 → M20
(Reporter)

Comment 13

19 years ago
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
Last Resolved: 19 years ago
Resolution: --- → FIXED
rubberstamp vrfy.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.