| managing the TCO of preferences/statefulness | Benoit Jacob | 5/14/12 7:20 PM | Hi,
Interesting blog post: http://blog.mozilla.org/verdi/166/the-new-reset-firefox-feature-is-like-magic/ So there is a significant number of people for whom clicking a button can suddenly make the browser better. How do we avoid getting there? Part of what 'Reset Firefox' does is reset the preferences which is the primary persistent state that we have from a platform perspective. Currently, correct me if I'm wrong, we're very lax about preferences. Just some examples: * it's easy to get r+ for a patch that subtly changes the meaning of an existing preference. * when adding preferences, we're not very careful about whether the state space contains "should never get there" states. * we do not remove old no-longer-used preferences. They stay around as unused state; if later we re-introduce a preference with the same name, we lose. * Preferences can be changed by add-ons, I believe. * Can preferences be changed by third party applications, and do we warn about that like we do for third-party-installed add-ons? What can we do? Random ideas: * do we already do preference fuzzing? * report on non-default-value preferences in crash reports, like we do in about:support (check possible privacy issues, maybe filter prefs) * do not allow add-ons to change arbitrary preferences. Maybe do not allow them to change real prefs at all, instead maybe just allow them to install an 'overlay' that overrides preference values as long as the add-on is enabled. * delete no-longer-used preferences? * check for self-conflicting preferences? * improve prefs API e.g. add enum preferences which would be better than plain integer preferences, string preferences, or multiple boolean preferences, as we currently use to emulate the missing enum preferences, creating many opportunities for corrupted state? Benoit |
| Re: managing the TCO of preferences/statefulness | Justin Lebar | 5/14/12 8:24 PM | > Random ideas:
I think most of these are probably solving a problem we don't have. If we make prefs a big commitment (I promise never to change the meaning, I promise to strictly error check, I promise to fix fuzz bugs), I'll just hardcode in values that I really should use a pref for. Even for values I intend to be static, using a pref makes it easy to deploy different values on desktop/mobile/b2g. In general, the browser can break if you mess with the prefs enough. I don't think this is a problem; we already display a pretty scary warning when you open about:config. And add-ons can arbitrarily break FF already; keeping them from breaking FF by modifying a pref doesn't solve anything. So I don't think we should make prefs harder for devs. However, this would be *incredibly fantastic*. Unfortunately I think this is harder than it sounds. IIRC we can't tell what's add-on code and what's Firefox code when we run chrome JS. We certainly can't tell in binary components. FWIW this is a hard engineering problem, but it's a comparatively simple problem to address via AMO policy. We could get 80% of the way there by saying that we'll take action against add-ons which don't follow our rules wrt prefs. That would address the Big Players, like Babylon Toolbar, which override awesomebar search prefs. We'd probably have to do something like this anyway, because we have no way to separate out existing prefs into an add-on's "overlay". Overlays would solve the problem only for prefs modified after we add overlays. Those who follow this list know it's an understatement to say that I'm pessimistic that we'd get anywhere by asking the AMO folks for help. But I want to emphasize here how dysfunctional this situation is. -Justin |
| Re: managing the TCO of preferences/statefulness | Mike Hommey | 5/14/12 10:33 PM | On Mon, May 14, 2012 at 11:24:27PM -0400, Justin Lebar wrote:For such preferences, we could use bug 440908 and ship them as locked, but with different values across different versions. Mike |
| Re: managing the TCO of preferences/statefulness | Mook | 5/14/12 11:18 PM | On 5/14/2012 8:24 PM, Justin Lebar wrote:
>> On 5/14/2012 7:20 PM, Benoit Jacob wrote:It can also be _easier_ than that; just make this opt-in (i.e. let the extension get at the prefbranch/whatever in a way that's associated with the extension). If you're using FUEL, for example, have an API like Application.getExtensions(function(e) e.get("bl...@example.com").prefs.setValue("hello", "world")); This might be a trade-off though - if it's implemented as loading extra user pref files on startup (one per extension), it might mean more seeks. But then we can just not load them for uninstalled extensions, and yet have them magically come back on reinstall. -- Mook P.S. Sorry for being mean and bringing up FUEL ;) |
| Re: managing the TCO of preferences/statefulness | Benoit Jacob | 5/15/12 5:44 AM | 2012/5/14 Justin Lebar <justi...@gmail.com>:
>> Random ideas: > In general, the browser can break if you mess with the prefs enough.But in addition to the user messing with prefs, and add-ons messing with prefs, there is also the case of us platform developers messing with prefs. I hear you about not making prefs harder for us, but how about this: For example, in Firefox 11 we were within hours of having to delay the release due to a top-crasher (bug 711656, bug 715401) that was caused by a preference having changed meaning subtly. If we had had modified preferences in crash reports, the bug would have been obvious, but without that, it's mostly due to luck that we identified the problem. If preference _values_ are too privacy-sensitive, put at least preference names in public crash reports. Also, many preferences are not privacy-sensitive at all so maybe add an API to allow specifying that. Likewise, > * delete no-longer-used preferences? Should not make it harder to use preferences, Should only be a matter of having to specify which preference combinations are incompatible, Should be making developers' life easier, not harder, by providing support for something we currently have to emulate in other ways. Example of a enum preference emulated as multiple bool preferences: webgl.disabled and webgl.force-enabled. We've had to answer several times the question "what if they are both true?". Same for layers.acceleration, gfx.direct2d, etc. Example of a enum pref emulated as integer preference: all the gfx.blacklist.* preferences. If we could have specified a symbolic constant (stored as a string) instead of a raw numeric value, we wouldn't have had the above-mentioned bug 711656. Cheers, Benoit
>> * do not allow add-ons to change arbitrary preferences. Maybe do not |
| Re: managing the TCO of preferences/statefulness | Justin Lebar | 5/15/12 7:28 AM | > * check for self-conflicting preferences?Sure, specifying the combination as incompatible is relatively simple once you know that the combination is incompatible. But like I said, I don't think our goal should be to make Firefox work with arbitrary preference values. If that were our goal, then surely we'd hardcode in more magic numbers instead of specifying them as prefs; that would be a net loss. (For example, I often have imagelib bugs which are easy to test for by moving a pref to an extreme value. If I hardcoded all these values because these prefs could break things, I'd lose my ability to test on released builds.) What would specifying and testing the domain of acceptable preferences buy us? I contend this is more work than you seem to think it would be... -Justin |
| Re: managing the TCO of preferences/statefulness | Justin Lebar | 5/15/12 7:36 AM | On Tue, May 15, 2012 at 1:27 AM, Nicholas Nethercote
<n.net...@gmail.com> wrote: > Babylon Toolbar isn't on AMO. Nor are many of the badly behaved add-ons. > > It might still be a good thing to have as AMO policy, but it would > just further increase the enforced quality gap between AMO and non-AMO > add-ons. I didn't mean to imply that the policy would be AMO-only. We have policies for non-AMO add-ons too. For example, they can't crash Firefox or cause "excessive" performance degradation. We claim that many of these add-on authors are our "partners". It seems reasonable to me that we might ask them to use a specific prefs API. I'd argue that we should enforce this through policy, but I expect that would be a non-starter with the add-ons folks. |
| Re: managing the TCO of preferences/statefulness | Jorge Villalobos | 5/15/12 8:10 AM | On 5/14/12 8:20 PM, Benoit Jacob wrote:This is already a policy we apply for AMO add-ons. They are not allowed to changes preferences unless it is necessary for their functioning and it doesn't surprise users. If they set the preference changes in the default preferences file (the recommended way), once the add-on is uninstalled the modified preferences will change back to their original value. It's worth noting that we have special warnings for preferences that we know shouldn't be changed or that have been problematic in the past (home page, user agent, etc.), so other preference changes might be overlooked. Jorge |
| Re: managing the TCO of preferences/statefulness | Jorge Villalobos | 5/15/12 8:10 AM | On 5/14/12 8:20 PM, Benoit Jacob wrote: > * do not allow add-ons to change arbitrary preferences. Maybe do not |
| Re: managing the TCO of preferences/statefulness | Benjamin Smedberg | 5/15/12 8:15 AM | On 5/14/2012 10:20 PM, Benoit Jacob wrote:Sure, addons can do anything. We encourage them to change the default preference values by providing a default pref file (in <extension>/defaults/preferences). This is better than setting "user" pref values because when the user disables the extension those values are no longer present. Extensions also use preferences as a place to store their own custom key/values pairs, in which case they are using user preferences. > * Can preferences be changed by third party applications, and do wePreferences are stored in the user profile. Sufficiently evil 3rd-party apps could simply read/write this file with different contents, yes. There is almost nothing we can do about this. > * report on non-default-value preferences in crash reports, like weWe absolutely cannot report the values of non-default preferences: that would violate all kinds of privacy principles. We could talk to the privacy folk about reporting the keys of modified preferences, but there are all kinds of variables here that make this difficult. And we'd still probably need to keep that data private so that only a small subset of people could see the key names, because they can probably be used to correlate reports. > * do not allow add-ons to change arbitrary preferences. Maybe do notMany addons store their own preferences. For SDK-based addons we could perhaps segregate the user values saved by that addon from user values stored by Firefox itself, but in the general case we cannot do that, because we don't know what code is calling into the preference service. > * delete no-longer-used preferences? Defining what a no-longer-used preference is very hard, and will affect addons. Just because a user disables an addon temporarily does not mean that they want all their addons preferences to be thrown away. > * check for self-conflicting preferences? > * improve prefs API e.g. add enum preferences which would be betterI really don't think we actually have a huge problem to solve here. Enums might be nice, but in terms of storage and backwards compatibility we'd probably continue to just store them as integers and make the API for fetching them do some bounds checking so that invalid values get ignored and we use a reasonable default instead (perhaps with a console warning). --BDS |