we need to add support to read preference values and set preference values through XPInstall. call them something like: getMozillaPref(name); setMozillaPref(name, Value);
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall Engine
moving out to m17, no need for beta 1
low priority feature, moving to m20 for now.
Target Milestone: M17 → M20
Parcelling out Cathleen's bugs
Assignee: cathleen → dveditz
Changing fictional "M30" to reality
Target Milestone: M30 → Future
Removing "Future" target to trigger reevaluation.
Severity: normal → enhancement
Priority: P3 → --
Summary: [feature] need support to read & set prefs → [feature] need support to read & set prefs in install
Target Milestone: Future → ---
Moz 0.9 tasks
Target Milestone: --- → mozilla0.9
FWIW, I have a very good use for this - changing translation provider for View | Translate, which is defined by two string prefs. Allowing other translation service providers to retarget that menu item with an XPI would be very cool. Gerv
Resetting milestone of all nsbeta1-bugs, only nsbeta1+ bugs should have a target milestone.
Target Milestone: mozilla0.9.9 → ---
Resetting milestone, only nsbeta1+ bugs can have a milestone on them, these are niminated, but not yet plussed.
We would need 2 (getter and a setter) method per pref value type (bool, int, char and complex), and perhaps a clearUserPref().
Created attachment 101480 [details] [diff] [review] Partial patch (only getCharPref/setCharPref) this is a partical impl, only has get/setCharPref. If people agree with this patch, I'll go do the others. I was considering just having a global nsIPrefService variable (like File) to minimize the amount of code needed, but could not figure out how to get that working.
Created attachment 104772 [details] [diff] [review] Better Partial patch (only getCharPref/setCharPref)
Attachment #101480 - Attachment is obsolete: true
Comment on attachment 104772 [details] [diff] [review] Better Partial patch (only getCharPref/setCharPref) r-, XPInstall scripts require a transaction model that so actions can be backed out in case of failure. Not sure what this patch would do if a script used this feature during a product install -- there's no real "profile" so you'd need to deal with that situation (by detecting it and returning an error during the "prepare" stage).
install.js is no longer supported
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.