289485 - prefs API needs to be improved

Status: RESOLVED INVALID

(Firefox :: Settings UI, enhancement)

Description

[Konstantin Svist]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

current API for preferences is quite hard to work with.
a few possible improvements:
- store preferences for extensions/themes by using their ID, but make that ID
invisible to the extension. Not only that would make it easier for developers to
name preferences but would also prevent a possible security problem if one
extension tries to modify another's preference. If it's not a security problem,
then access to a pref via ID should be optional (nobody wants to write
"getmypref('{12345-12345-12345-67890-abcde}.foo');" )
- create access functions that will let an extension to clear all old
preferences for its ID, set all its preferences to defaults (provided by the
extension). At the same time, the extension manager/installer should read data
from install.rdf file and see if any old preferences need to be cleaned up. For
example, extension A version 1 created two preferences: foo and bar. User set
foo=true and bar=true because the extension allowed for both. Later, extension A
is upgraded to version 2, which doesn't let the user set both foo and bar to
true but doesn't fail if they are both true. Later still, extension A is
upgraded to version 3, which assumes that everyone is upgrading from v2 (because
what sensible person would stay with v1 for a year, right? haha, let's just say
the author forgot about it :P). This time both foo and bar can't be true at the
same time and the extension fails if they are. Under current preferences
management, the extension has to clean the preferences manually and has no idea
from which version it was upgraded. If the installer is given such data as
"reset all my prefs if previous version was below 1.2" it can easily accomodate
that request.
- provide an interface to import/export sets of preferences. Some extensions
provide such an interface themselves but each extension author has to code it up
and they all end up being in proprietary formats, etc. It's a pain in the as..neck


Reproducible: Always

Comment 1

[Nickolay_Ponomarev]

Please file separate bugs for separate requests.

Number one isn't something I think is worth adding to prefs system. You can just
get a pref branch for "extensions.yourguid." and then just work with that.

Things like in your number two should be dealt with in extension code imho,
though I'm not sure I understand what exactly you request there.

Number three seems like a valid enhancement request, but please file it as a
separate bug.

Comment 2

[Konstantin Svist]

(In reply to comment #1)
> Please file separate bugs for separate requests.

Okay, will file 3rd one separately but discuss the rest here if you don't mind -
don't need several extra bugs for discussion :)

For #1, do you mean that it's not a security issue? (I'm not saying it is, I'm
asking). If nothing else, it would make #3 easier to implement.

For #2, I'm asking to add functionality to extension manager/installer so it
would be able to clean out old preferences for any extension you install.
Cleaning out old prefs is something that needs to be done but is often
overlooked by extension developers (myself not excluded, I'm ashamed to say).
I've seen myself what happens with stale extension preferences.. I had to clean
out my profile directory and reinstall the 50 or so extensions because the
problems piled up, especially from alpha/beta versions and basic browser
functionality stopped working (search-as-you-type, for example). Implementing #2
would make it easier for the extension developer to clean out old preferences if
it's necessary. Or this can be written as part of the install process: for
example, if the user installs a new version of an extension, the installer asks
the user if they want to override the old preferences.
I'm worried that conflicts with extension preferences might turn into something
similar to the so-called "DLL Hell" in older versions of ms-windows

let me know what you think

Comment 3

[Nickolay_Ponomarev]

Disclaimer: I'm just an extension developer
#1 - it's easy to create a branch to store your prefs in. Restraining access to
other prefs reduces the power of extensions. They just should be civil and don't
touch prefs they don't need to touch. (It's really easy to screw up Firefox from
an extension, even without touching prefs.)

#2 - I think it's responsibility of an extension to clean up after its own
previous versions, but it's not me who decides, so please file a separate bug on
that; let this be about #1.

Comment 4

[Nickolay_Ponomarev]

Okay, invalid as many-reports-in-one-bug. Number one is certainly not a security
problem and will not be fixed, probably. If you like, you may file bugs for
other things (one bug per issue, please), but I personally don't think #2 will
ever be implemented (it's an extension problem, really), and I think I have seen
a bug for #3, so search before filing that.

Comment 5

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change